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I.   AN  INTRCCUCTICN 

Although  the  application  of  software  database  rranaqerrent 
systems  to  user  reaulrerrerts  is  rot  new  there  are  eirerging 
special-purpose  hardware  systeirs  which  will  relieve  the  host 
central  processing  unit  (CPU)  from  the  time  consuming 
processes  of  accessing,  updating,  and  modifying  data. 
Numerous,  ccmmercially-availafcle  software  database 
management  systems  for  the  host  computers  are  currently 
employed  in  application  areas  but  there  appears  to  be 
associated  performance  degradation  in  the  host  machines. 
These  performance  issues  must  be  identified  and  performance 
measured  In  order  to  provided  seme  quantitative  comparisons 
between  software  systems,  general-purpose  hardware  systems, 
and  special-purpose  hardware  systems.  Historically  this 
information  has  been  collected  for  general-purpose  computers 
by  the  use  of  the  instruction  mix  (Gibson  or  Flynn)  to 
measure  performance  in  various  categories.  This  measurement 
of  a  machine  using  an  instruction  as  a  tool  mix  is  called 
benchmarking. 

The  tas)c  of  benchmarking  a  database  system  has  not  been 
developed  in  the  literature.  Consequently,  a  research 
project  has  ceen  undertaken  by  the  Naval  Postgraduate  School 
to  develop  a  set  of  benchmarking  standards  which  can  be 
employed  to  obtain   a   performance   index   of   a   particular 


10 


database  macnine/systerr:  and  further  used  In  a  corrcarative 
analysis  with  respect  to  ether  datacase  systerrs/machines. 

The  initial  steps  in  the  benchrnarK  development  have  been 
liirited  to  a  specific  relational  database  machine.  In 
addition  to  the  ireasurerrents  of  specific  database 
operations,  a  question  of  the  role  and  responsibilities  of 
the  database  adrrinlstrator  (DBA)  is  posed,  i^-ith  each  systerr 
benchirarKed,  there  is  a  need  to  establish  the  airount  of 
support  provided  to  DBA,  In  this  case  an  exatrination  of  the 
facilities  provided,  query  language  employed,  and  amount  of 
additional  DBA  support  required  is  conducted. 

The  objective  of  this  thesis  is  to  categorize  the  duties 
and  resconsibilitles  of  CSA  and  descrloe  how  they  are 
supported  by  the  benchmarKed  systenr.  At  the  beginning,  the 
system  environment  is  described,  followed  by  a  discussion  of 
the  query  language.  An  analysis  of  DBA  functions  is  then 
made  and  finally,  the  fully  relational  model  is  examined  and 
a  comparison  of  this  particular  query  language  with  another 
well-known  language  is  made. 

This  thesis  is  one  in  a  series  of  four  describing  the 
current  status  of  the  benchmark  development.  The  other 
three  topics  are  on  generating  the  synthetic  database  CRef, 
13,  selection  and  projection  [fief,  21,  and  join  operations 
CRef,  3], 
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II,   THE  BENCHMAPKING  &NVIRCNMENT 

A.  THE  HOST  SYSTEM 

The  host  rrachlne  for  the  benchmark  is  Univac  1100/42 
located  at  Pacific  Missile  Test  Center,  Point  Muqu, 
California,  In  addition  tc  or-site  eaulptrent,  a  remote 
teririnal  is  Installed  at  the  Naval  Postgraduate  School, 

1  •   The  Hardware  Interface 

The  hardvore  interface  between  the  host  and  the 
database  machine  is  through  a  Univac  1100/42  I/O  channel. 
This  interface  channel  has  a  200-thousand  byte/second 
capacity  and  the  transirissicr  unit  is  either  a  byte  or  a 
word, 

2.   The  Software  Interface 

The  host  software  is  written  by  Arroerif  Corporation 
of  Chatsworth,  California,  This  software  consists  of  the 
host-driver  routines  whose  prirrary  purpose  is  to  parse  the 
queries  and  to  translate  thenr  into  the  dataoase  machine 
language.  Finally,  the  host  handles  the  communications 
protocol  between  the  database  machine  and  itself, 

B.  THE  8ACKEND  DATASASE  MACHINE 
1  •   A  Modular  Cesion 

The  database  machine  which  interfaces  with  the  host 
is   an   IDm   50C  manufactured  by  Eritton-Lee  incorcorated  of 
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Los  Gatos,  California,  IDW  SCO  is  being  trarlceted  by  Amcerif 
Corporation  as  an  RDM  llOO,  It  is  a  modular,  expandable, 
and  iTlcroprocessor-based  systenr  organized  around  a  central 
high-speed  bus.  The  separate  modules  are  functionally 
oriented.  The  RDM  1100  eirploys  the  relational  database 
model  which  *ill  be  discussed  in  detail  in  Section  v. 

The  database  processor  (Z8000-based  microprocesscr) 
supervises  and  inanages  all  systeir  resources.  This  processor 
executes  rrost  of  the  software  ir  the  system. 

The  database  accelerator  is  an  ortional,  high-speed 
processor  with  an  instruction  set  specifically  designed  to 
perform  certain  relational  database  functions.  The 
accelerator  has  a  three-stage  pipeline  which  executes 
instructions  at  up  to  10  MI?S,  This  processor  can  initiate 
disk  activity  and  can  process  data  at  disk  transfer  rates. 
The  accelerator  and  the  RDM  llCC  software  are  so  configured 
that  the  most  frequently  occurring  database  worx  is 
performed  by  the  accelerator  under  the  direction  of  the 
database  processor. 

The  cache  memory  (i.e.,  main  memory)  of  RDM  lioO  is 
composed  of  64K-bit  chips  of  dynamic  RAM,  it  may  be 
expanded  to  a  maximum  of  six  megabytes.  This  cache  is 
utilized  for  RDM  1100  system  code,  disK  caching,  indices, 
and  user  commands, 

DlsK  Controller  modules  may  be  expanded  from  one  to 
four.    Each   controller   can   manage   from  one  to  four  disK 
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drives.  The  6is<  controller  rroves  data  oetween  the  disks 
and  the  cache  irerrory,  and  is  designed  to  work  with  the 
accelerator.  An  optional  tape  control  module  supports  up  to 
eight  tape  drives  v^hlch  can  be  used  for  direct,  disk-to-tape 
backup,  data,  and  software  loading, 

RDM  1100  and  the  host(s)  cotrrrunicate  with  each  other 
via  RDM  llOO's  host-interface  rrcdule.  Ihis  module  accepts 
cotrirands  frorr  one  or  rrore  hosts,  and  acts  on  those  comirards 
accordingly.  Each  host-interface  module  can  handle  up  to 
eight  hosts  and  a  iraximum  of  eight  host-interface  modules 
can  be  made  available  on  HDy  llOO,  Hence,  a  maximutr.  of  64 
hosts  can  be  accommodated  by  RCi^  llOO,  In  addition  to 
communications  handshaklno  protocols,  the  interface  module 
performs  necessary  error  checks  and  causes  the  host  to 
retransmit  any  information  block  in  which  an  error  is 
detected,  CRef,  4] 

2,   The  System  Configuration 

In  the  configuration  described  above  Cl,e,,  the 
connection  of  the  host  and  the  database  machine  with  an  I/Q 
channel),  the  database  machine  is  called  a  backend  database 
machine.  The  term,  'backend',  is  used  in  this  context  to 
refer  to  a  special-purpose  machine  operating  as  a  peripheral 
device  on  one  or  more  host  systems.  As  previously 
mentioned,  the  use  of  the  backend  machine  can  significantly 
reduce  the  required  CPU  time  for  data  manipulation  by  the 
host.   Further  advantages  are  realized  through  freeing   disk 
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space  on  the  host  and  the  reduction  of  I/O  cycles;  thus 
releasing  the  CPU  to  perforrr  other  functions  necessary  for 
the  proper  operation  of  the  system  and  execution  of 
applications  programs. 

The  performance  of  PDN«  1100  is  highly  dependent  on 
the  available  hardware  configuration.  Other  performance 
Issues  such  as  indexing  and  data  positioning  are  dependent 
on  the  software  developed.  The  hardware  configurations  are 
discussed  below  and  the  software  issues  are  discussed  in 
Section  IV, 

Four  test  configurations  are  used  during  the  course 
of  this  research.  The  initial  configuration  is  of  one-half 
megabyte  of  cache  without  the  accelerator.  This 
configuration  will  not  be  marketed  cy  Amoerlf,  but  is  tested 
for  the  purpose  of  comparison.  The  next  test  configuration 
is  of  one-megabyte  of  cache  with  the  accelerator.  Following 
it,  a  two-megabyte  cache  with  the  accelerator  is  tested. 
Finally,  the  accelerator  is  removed  from  the  configuration. 
The  configuration  is  tested  with  only  the  two-meqabyte 
cache.  The  standard  commercial  configuration  is  with  one- 
megabyte  of  cache.  The  accelerator  is  an  optional  feature. 
For  specific  information  en  the  performance  measurements, 
the  reader  is  directed  to  CRef,  23  and  tRef.  33, 


15 


Ill,   THE  RELATICNAL  QUERY  LANGUAGE 

A,   AN  INTRQDUCTICN  TC  THE  LANGUAGE 

In  addition  to  the  hardware  and  software  to  support  the 
host/baclcend  Interface,  Ajrperlf  also  provides  a  language  for 
reauesting  inforrration  cr  operations  on  data  from  the 
backend  database  rrachlne.  This  language  is  called  the 
Relational  Query  Language  (RQLK  The  language,  being  tne 
only  interface  for  the  user  and  database  adrrinistrator 
(DBA),  is  the  sole  means  by  *hich  the  capabilities  and 
limitations  of  the  backend  are  known  to  the  user  and  DBA, 
Therefore,  a  discussion  about  the  facilities  of  RCL  will  be 
presented. 

This  section  defines  t'*(0  major  command  groups  available 
in  RQL,  The  metanotaticn  used  in  tne  command  syntax 
consists  of  the  symbols  described  below. 


(   ) 
C   ] 


<       } 


<      > 


used  as  delimiters  in  RQL 

used  to  indicate  anytnino  optional  inside 

the  square  brackets 

used  to  denote  a  chcice  of  the  word  eitner 

before  or  after  the  bar 

used  to  specify  zero  or  more  occurrences  of 

anything  in  the  curly  brackets 

used  as  metasymbols  to  denote  a  construct  in 
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ROL  with  the  naire  of  the  construct  between 
the  metasyrrbols 

All  other  woros  In  RQL  are  key  words  and  trust  appear 
literally  CRef.  5].  In  the  rerralning  sections  Key  words  are 
capitalized.  In  sections  explaining  the  coirrrands,  an 
abbreviated  syntax  of  each  command  followed  by  an 
explanation  of  the  coirrnand  is  proviaed,  Ihis  inf orrration  is 
taken  from  CRef,  53  and  CRef,  6J  , 

B.   DATA  DEFIMTICN  COMMANDS 

In  ROL  the  coirmands  are  presented  without  reqard  to 
function.  However,  in  rrost  database  books,  (e,q,,  [Kef.  7] 
and  CRef,  83),  there  is  a  distinction  between  the  data 
definition  language  and  the  data  manipulation  language. 
Although  this  distinction  is  not  irade  in  ROL,  it  provides  a 
logical  division  of  the  majority  of  commands  and  facilitates 
the  understanding  of  the  corrmands,  Ihe  data  definition 
language  consists  of  those  ccrrrrands  which  are  used  for  the 
description  of  database  objects. 

Data  can  be  represented  in  seven  different  types  in  RDM 
1100,  The  two-character  specifications  available  are  for 
the  compressed  Cc)  and  uncompressed  (uc)  character  string 
with  the  user  providing  a  maximum  length,  up  to  255 
characters.  The  difference  is  that  the  compressed  character 
string  is  not  stored  with  trailing  blanks.  Integers  can  be 
declared  witn  three  different  byte  sizes  namely,  1,  2,  or  4, 
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The  byte  size  of  an  attribute  llirlts  the  precision  which  can 
be  accommodated  in  the  attribute  values.  Finally, 
floating-point  nunrpers  can  also  be  expressed  as  coiTpressed 
(f)  or  uncompressed  (uf).  The  range  provided  by  these  t*o 
forms  is  identical  and  of  31  significant  digits.  As  in 
character  strings  the  user  rrust  specify  the  number  of 
significant  digits  desired.  The  difference  oetween 
compressed  and  uncompressed  floating  point  is  the 
suppression  of  leading  and  trailing  zeros  in  the  compressed 
floating  point.  Compression  is  a  feature  designed  to  reduce 
the  storage  reguirement  in  the  database,  ine  following 
declaration  is  an  example  of  the  use  of  attribute  types: 

name  s  c25,  salary  =  uf8,  age  a  11,  address  =  c200. 

This  example  establishes  four  attributes:  'name'  whose 
values  can  each  consist  of  up  to  25  characters,  'salary' 
whose  values  are  floating-point  numbers  each  of  which  is  of 
eight  significant  digits,  'age'  whose  values  are  cne-byte 
integers,  and  'address'  whose  values  are  character  strings 
of  up  to  200  Characters  each.  Notice  'name'  and  'address' 
are  designated  as  compressed  and  therefore  trailing  blanks 
of  their  values  are  not  stored, 
1  •   To  Create  a  Database 

CREATE  DATABASE  <name>  t«ITH  <options>] 
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This  corrinand  Is  used  to  establish  a  database  >rhich 
will  be  referred  to  by  the  user-specltled  name.  The  txo 
options  orovided  are  DISK  and  CEWAwD,  DISK  allows  the 
specification  of  one  or  incre  disks  on  which  the  database 
will  be  stored  (e.g.,  DISK  »  'sys').  DL>^AND  specifies  the 
nurrber  of  2K-byte  blocXs  to  be  allocatea  for  the  database. 
If  the  database  grows  beyond  the  allocated  clocXs,  it  Tiay  ce 
extended  with  the  following  ccrrrrand: 

EXTEND  DATABASE  <na»Te>  ftlTH  <oPtlons> 

The  options  are  identical  to  the  options  of  CREATE  DATABASE. 
2.   To  Create  a  Relation 

CREATE  RELATION  <narre>  C<attrlbute  natre>  =  <forirat> 
{,  <attrlbute  naira>  =  <fornnat>>)  twiTH  <optlons>] 

The  create  corrmand  is  used  to  establish  the  schenna 
for  a  relation.  An  eirpty  relation  is  set  up  in  the  database 
when  the  corriTiand  is  executed  with  the  actual  specification 
of  the  attributes  In  parenthesis  being  given  as  depicted  in 
the  example  of  data  types  above,  Cne  posslcie  option  which 
may  be  declared  is  LOGGING,  This  option  causes  every  cnange 
to  the  relation  to  be  logged  in  the  oataoase  transaction 
log.  This  feature  is  extremely  Important  to  maintain  the 
consistency  and  integrity  of  the  relation  when  system 
recovery  must  be  initiated. 
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3,  To  Create  an  Index 

CREATE  CUMGUE3  [NONCLUSTERED  I  CLUSTERED]  INDEX 

CCN3  <ocject  narre>  (<attribute>  {,  <attrifcute>> ) 

An  index  on  an  attribute  cf  a  relation  provlaes  a 
direct  access  to  the  attribute  values  in  the  relation,  A 
unique  index  on  an  attribute  requires  ail  attribute  values 
to  be  different.  There  are  two  primary  oifferences  between 
clustered  and  nonclustered  indices,  A  clustered  index  is 
nondense  (i.e.,  one  entry/block)  wnereas  the  nonclustered 
index  is  dense  (i.e.,  one  entry/tuple).  The  second 
difference  relates  to  the  storage  of  oata,  Althouqn  the 
nonclustered  index  does  not  affect  the  placement  of  data, 
the  clustered  index  requires  the  tuples  of  the  relation  to 
be  stored  in  the  order  of  the  attrioute  values. 
Consequently,  only  one  clustered  index  rray  be  created  for  a 
relation  whereas  250  nonclustered  indices  may  be  defined  for 
the  same  relation.  For  performance  data  on  ocerational 
enhancement  provided  oy  indices,  see  [Ref,  23  and  CRef,  3], 

4,  To  Create  a  View 

CREATE  VIE'*  <view  name>  (<target  llst>) 

[WHERE  <oualif ication>3 

The  CREATE  VIE^^  command  establishes  a  virtual 
relation,  i.e,,  there  is  no  storage  of  tuples  assoclateo 
with  the  view,   A  view  is  a  composite  relation  (without   its 
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own  tuples)  of  attributes  frcir  other  relations  or  vie 'as. 
The  target  list  is  the  list  of  attributes  desired  tro^  the 
other  relations  or  views.  Finally,  the  Qualification  allCAS 
the  user  to  restrict  tne  quantity  ot  data  in  the  view  to  a 
particular  category  and  to  provide  necessary  linKaces 
between  the  relations  or  views. 

5.   To  Define  a  Stored  Ccnrrand 

DEFINE  <stored  corrrrand  rarre> 
<co(rrrand>  {<ccfrirand>> 
EMD  DEFINE 

In  ROL  the  DEFINE  ccttrard  provides  a  mechanism  for 
creating  subroutines  in  the  database  machine.  Stored 
coirmands  fray  have  parameters  or  be  parafreterless ,  Tne 
<COiTniand>  can  be  an  APPEND,  DELETE,  REPLACE,  RETRIEVE,  etc. 
(to  be  discussed  later).  There  are  t*o  aavantages  to  stored 
corrrrands.  One  is  that  it  relieves  the  operator  of  retyping 
a  frequently  ernployed  ccrrrrard  and  allows  the  DBA  to  provide 
a  a  simplified  method  for  irvcking  complex  queries.  The 
second  and  perhaps  most  important  advantage  is  the 
performance  enhancement.  Since  the  storea  command  exists  in 
the  database  with  all  addresses  of  cited  relations  resolved, 
the  communications  between  the  host  ana  the  bacKena  machine 
is  reduced  to  passing  an  EXEC  tc<en  and  the  command  name. 
Examples  of  stored  commands  are  provided  in  Appendix  A, 
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6,  To  Destroy  a  Catabase 

DESTRCY  DATABASE  <narre> 

The  DESTRCY  DATABASE  corrrnand  eliminates  the  entire 
database  by  rerroving  all  linkaqes  froT  RDM  iiOO  and  freeing 
the  storage  space, 

7,  To  Destroy  an  Object 

DESTRCY  <object  narre> 

This  coirmand  elirrinates  existing  relations, 
established  views  or  stored  ccirirards  from  the  database.  The 
space  freed  by  the  command  is  reusable  by  the  database.  As 
indicated  previously,  viev»s  and  stored  commands  depend  en 
existing  relations  or  views.  These  underlying  objects  are 
said  to  have  dependencies.  An  cbject  *hich  has  dependencies 
cannot  be  destroyed  without  first  destroying  the  dependent 
Object,  This  does  not  apply  to  Indices,  wnich  are 
automatically  destroyed  when  the  relation  is  destroyed, 

8,  To  Destroy  an  Index 

DESTRCY  [NCNCLUSTERED  I  CLUSTERED]  INDEX  [ON] 
<object  name>  C<attribute  name> 
<,  <attribute  natre>>) 

If  an  index  is  unnecessary  or  the  overhead 
associated  with  Keeping  an  index  is  to  high,  the  index  may 
be  deleted  from  a  database  by  the  DESTROY  INDEX  command.   In 


22 


addition  to  the  cfcject  narre,  the  user  must  also  specify  the 
exact  attributes  ot  the  index  fcr  the  purpose  of  avoiding 
any  airbigulty, 

C,   DATA  MANIPULATION  COWHANDS 

The  data  tranipulatlon  language  is  that  subset  of  RQL 
comrrands  which  allows  the  user  to  access,  update,  and 
retrieve  the  data  stored  in  the  database, 

1,   To  Retrieve  Data 

RETRIEVE  [UNIQUE]  (<tarqet  list>)  [ORDER  [BY]  <order 
specif ication>  [:A  I  D] 
{,  <order  specif lcation>  [:A  I  D3>] 
[WHERE  <auallflcation>] 

The  RETRIEVE  coipmand  is  the  most  commonly  employed 
command  in  RQL.  It  is  the  means  by  which  data  is  extracted 
from  the  database  and  returned  to  the  user.  The  target  list 
provides  the  user  with  the  facility  to  reduce  the  amount  ot 
data  by  limiting  the  number  ot  attribute  values  reauested. 
The  format  for  the  target  list  is: 

relation.n am e, attribute. name 

[,  relation. name, attribute.name] . 

This  list  of  attributes  can  be  from  one  or  more  relations. 
To  reduce  duplicate  information,  unique  can  be  employed. 
The   order   specltlcation   dictates   the   order    Cl,e,, 
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alphabetic,  nurrerlc  or  alphanurreric  order)  In  which  the  data 
is  to  be  sorted.  Finally,  the  Qualification  allov^s  tne  user 
to  specify  predicates  which  the  data  trust  satisfy  and  to 
require  linkages  between  relations.  These  predicates  and 
linkages  reduce  the  nuiTiber  of  tuples  retrieved, 

2,  To  Append  ivew  Tuples 

APPEND  tlC]  <relatlon  name>  (<vaiue  list>) 
[WHERE  C<gualitication>)] 

The  APPEND  cofTinand  allocs  the  user  to  add  tuples  to 

a  specific  relation.  The  value  list  must  specify  the 
attribute  names  and  attribute  values  with  an   equality   sign 

in  between.   Unlisted  attribute  values  in  the  value  list  are 

assigned  default  values  Ci,e.,  blanks  for  characters  and 
zeros  for  nurrerals), 

3,  To  Replace  Attribute  Values 

REPLACE  <relation  name>  (<value  list>) 
(WHERE  <qualif ication>) 

REPLACE  provides  the  facilities  for  updating  values 
stored  in  the  database.  Although  it  can  only  change  one 
relation  at  a  time,  the  number  cf  attribute  values  is  not 
limited.  Further,  more  than  one  relation  can  be  accessed  to 
calculate  what  is  to  be  updated.  Although  a  view  name  may 
be  used  in  place  of  the  relation  name  in  REPLACE  and  APPEND 
commands,  the  numerous  restrictions  on  the  acceptability   of 
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tMs        procedure      irakes      It      alrrost      Impotent      and      at      best 
Infeaslble, 

4,  To  Delete  Tuples 

DELETE  <relation«nafre>  [WHERE  <quallf lcatlon>] 

This  coirrpand  Is  used  to  retrove  one  or  more  tuples 
from  a  relation.  If  a  aHERE  clause  is  not  specified  then 
all  tuples  will  be  deleted, 

5,  lo  Aggregate  Attribute  Values 

There  are  six  scalar  aggregates  supplied  in  RQL 
whicn  may  be  applied  to  one  or  nrore  attribute  values.  These 
aggregates  return  a  single  value,  known  as  tne  scalar,  to 
the  user.  The  results  of  "^IN  and  max  are  tne  smallest  ana 
largest  attribute  values  found  for  the  attribute, 
respectively,  SUM  and  AVG  provide  the  arithmetic  total  and 
mean  of  the  respective  attribute  values.  COUNT  returns  the 
number  of  occurrences  of  the  specific  attricute  value,  ANY 
Is  used  to  test  for  the  existence  of  a  soeciflc  attribute 
value.  This  is  accomplished  cy  appiyina  Ai>«Y  to  a  condition 
Ce.g,,  ANY  s  (relation, name, attribute. name  s  value)).  If 
the  condition  is  true  for  at  least  one  attribute  value  a  '1' 
is  returned,  '0'  otherwise.  Any  scalar  aggregate  can  have  a 
predicate  (qualification)  and,  since  it  returns  a  single 
value,  can  be  used  anywhere  a  scalar  value  is  permisslole  in 
an  expression  or  other  predicate,  UNIQUE  can  be  used  with 
COUNT,  SU^,  and  AVG  to  avoid  including  duplicate  entries   in 
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the  computed  scalar  value.  For  exairpie,  COUNT  UNIQUE  can  be 
used  on  a  personnel  database  to  retrieve  the  nurrber  ot 
different  states  (assurnlng  birthplace  Is  an  attribute) 
represented  by  the  employees  place  of  oirth  without  regard 
to  the  actual  number  of  employees  from  each  state,  Ihese 
scalar  aggregates  are  useful  In  providing  statistics  about 
the  database  and  in  Isolating  tuples  whose  attribute  values 
are  numeric.  For  example,  a  query  can  be  composed  to 
provide  a  list  of  attribute  values  such  that  each  value  is 
greater  than  the  average  of  the  values. 
(3,   Aggregate  Functions 

The  term  'function'  is  misleading  when  used  in  this 
context  since  the  results  cf  applying  an  aggregate  function 
is  a  list  of  scalars.  Although  this  is  not  the  generally 
accepted  concept  of  a  function  (returning  a  single  value)  in 
the  literature,  it  win  continue  to  be  used  in  this  thesis. 
Aggregate  functions  are  used  in  conjunction  *itn  the  'group 
by'  (EY)  clause.  This  clause  provides  a  oartition  of  the 
attribute  values.  The  partitioned  values  can  then  oe  used 
as  arguments  cf  an  aggregate  function,  Tnere  can  be  more 
than  one  aggregate  function  in  a  query,  and  aggregate 
functions  may  be  nested.  Additionally,  aggregates  may 
appear  in  both  the  target  list  and  qualification.  An 
example  of  the  application  cf  an  aggregate  function  can  be 
found  in  Section  v. 
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The  aggregate  functions  provide  the  corrrutatlonal 
power  of  RQL.  ifldthout  the  functions  there  would  be  no  easy 
method  of  dividing  attribute  values  into  sets  and  performing 
tests  or  computations  on  these  value  sets.  Further,  the  use 
of  aggregate  functions  relieves  the  user  from  creating 
numerous  tetrporary  relations  and  from  manipulating  them 
individually  for  the  desired  result.  For  example,  in  a 
personnel  relation  with  salaries  and  department  numoers  as 
attributes,  it  may  be  desirable  to  compute  the  average 
salary  of  each  department.  This  is  easily  accomplished  by 
the  use  of  the  aggregate  function  in  the  target  list  as 
follows: 

answer  =  AVG  (salary  by  dept-no). 

If  this  capability  were  not  available,  some  other  form  of 
partitioning  would  be  required  to  support  the  query.  Cne 
might  provide  a  separate  retrieve  for  each  department 
number,  form  a  temporary  relation  for  the  retrieved  salary 
figures,  and  average  on  the  newly  formed  relation 
separately. 

7.   String-Manipulation  Functions 

In  order  to  maintain  the  simple  format  of  a 
relational  system  and  yet  provide  the  caoability  to  obtain 
data  based  on  partial  or  combined  attributes,  RQL  Includes 
three  string  manipulation  functions.  The  most  useful  of  the 
three  for  the  user  appears  to  be  pattern  matching.   By  using 
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syrrbols  to  represent  any  nurrber  of  characters,  tuples  having 
a  desired  Internal  pattern  in  a  specific  attribute  can  te 
selected.  Again,  consider  a  personnel  relation  v^ith  an 
attribute  of  date  of  birth.  The  pattern  matching  function 
could  oe  used  to  provide  a  list  of  all  personnel  born  in  a 
particular  ntonth.  Pattern  rratcning  applies  only  to 
characters  and  is  only  used  in  predicates. 

The  other  t*o  functions  are  cOnCAT  and  SUBSTRING. 
These  functions  can  be  used  v^ith  character  or  binary 
attributes,  CCNCAT  reauires  t*o  string  arguments,  strips 
all  trailing  blanks  from  both  strings  and  concatenates  the 
second  string  to  the  first.  The  SbbSTRlNG  function  requires 
a  starting  position  in  the  string,  a  length  to  define  the 
number  of  characters  desired,  and  the  attribute  on  xhich  to 
perform  the  operation.  For  an  example  of  SUbS'lRING 
employment,  see  Appendix  A, 

8,   System  Supplied  Functicrs 

There  are  three  categories  of  system  supplied 
functions  available  in  RQL.  These  provide  information  about 
the  database  and  host,  cross  reference  of  system  assigned 
identification  numbers  to  associated  character  strings,  and 
data  type  conversions. 

The  first  group  of  functions  is  oarameterless  and 
provide  general  information  about  the  host  and  database.  For 
example  a  user  may  request  the  name  of  the  database 
CDATABASENAME   C)J,   the  time  or  date  CGETTI.me  ()  or  GETDATE 
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C)],  the  attached  host  [HOST  ()3,  the  Identity  of  the  CBA 
CDBA  ()],  or  Who  Is  executing  a  ccrrtrand  CuSfcRID  ()3. 

The  second  group  of  functions  is  useful  in  providing 
information  in  a  meaningful  forir  to  the  user.  There  are 
three  self-explanatory  ccrrrrands  in  this  group  [RfL_ID 
(relation  name),  RKL.NAWE  (relation  ID),  and  field.name 
(relation  ID,  attribute  ID)).  These  translations  are  used 
extensively  in  Appendix  A, 

The  last  group  provides  the  capacillty  to  convert 
expressions  (exp)  from  one  data  type  to  another.  For 
example,  a  user  may  convert  an  expression  to  a  1-,  2-  or  4- 
byte  integer  CINTl  (exp),  INT2  (exp)  or  IM4  (exD)J,  a 
binary  number  [BIN  (exp)],  or  a  floating-point  number  CFLCAT 
(length,  exp)].  The  expression  can  be  any  one  of  the  other 
types  listed  as  well  as  string  and  binary  coded  decimal  in 
there  legal  forms  (e.g.,  compressed  and  uncompressed), 

D,   EXPRESSING  THE  RELATIONAL  CFERATIGNS  IN  THE  QUERY 

LANGUAGE 

The  power  of  a  relational  query  language  is  usually 
measured  oy  its  ability  to  perform  the  operations  specified 
in  relational  algeora  or  relational  calculus.  Since  the 
equivalence  of  the  two  has  been  demonstrated  CRef,  8],  the 
relational  algebra  will  be  used  for  comparative  purposes 
without  loss  of  generality.   It  should  oe  noted  that  RQL  is 
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probably  best  characterized   as   a   domain-based   relational 
calculus. 

The  relational  algebra  supports  four  traditional  set 
operations  (Union,  Intersection,  Difference,  and  Cartesian 
Product)  and  four  special  relational  operations  (Selection, 
Projection,  Join,  and  Clvislcn).  All  eight  ©Derations  will 
be  defined  and  an  example  of  each  in  RQL  will  oe  provided. 
In  the  examples  the  term,  relation. natre,  will  be  abfcreviatea 
to  'rel*  and  the  term,  attribute. name ,  to  'attr'. 

1 .  The  Selection  Operation 

The  selection  operation  provides  a  subset  of  tuoles 
in  a  relation  which  satisfy  a  given  qualification.  All 
attribute  values  of  every  tuple  satisfying  the  predicate  are 
included  in  the  subset,  FOL  provides  an  ALL  Keyword  which 
slrrplifies  the  selection  operation  cy  avoiding  the 
enumeration  of  every  attribute  in  the  target  list, 

RETRIEVE  UNIQUE  (rel,ALL)  wriERE  <quali f lea t ion> 

2.  The  Projection  Cperatlcn 

Projection  is  used  to  reduce  the  number  of  attribute 
values  in  the  tuples  which  Tai<e  up  the  selected  subset.  In 
addition  to  limiting  the  nuircer  of  attribute  values  in  a 
tuple,  the  projection  operation  also  deletes  duplicate 
tuples  from  the  suoset.  Deleting  duplicates  can  be  enforced 
by  using  the  optional  keyword  UMGUE,  Projection  in  ROL  is 
a  function  of  the  target  list  ir  the   retrieve   command,    A 
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qualification   rray  be  used  to  reduce  the  number  of  tuples  as 

In  selection.   To  reiterate,  selection  reduces  tne  nun-ber  of 

tuples   whereas   projection   reduces  the  number  of  attribute 
values. 

RETRIEVE  UNIQUE  (rel.attrl,  rel,attr2,  ...,  attrn) 
WHERE  <quallf lcation> 

3.   The  Join  Operation 

The  join  operation  rray  be  performed  on  any  number  of 
relations  whose  attributes  are  defined  over  a  common  domain. 
The  result  of  the  join  is  a  new,  higher-degree  relation. 
Each  tuple,  in  the  resultant  relation,  is  formed  oy 
concatenating  tuples  from  the  source  relations  whose 
attribute  values  satisfy  the  qualification. 

There  are  different  qualifications  and  therefore 
different  joins.  The  equl-jcln  is  formed  over  an  equality 
predicate.  The  inequality  jcln  is  formed  over  an  inequality 
predicate  with  an  operator  such  as  <,  >,  <=,  >s  or  !=,  The 
following  is  an  example  of  an  equl-join;  the  other  joins  can 
be  realized  by  manipulating  the  target  list  (natural  join) 
or  predicate  (inequality  join),  accordingly. 

RETRIEVE  UNIQUE  (rell.ALL,  rel2.ALL) 

WHERE  rell.jcinattr  =  rel2, joinattr 
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4.   The  Division  Cceratior! 

The  division  operation  is  defined  for  two  relations 
in  which  the  divisor  relation  has  a  degree  less  than  the 
degree  of  the  dividend  relation.  The  resultant  relation  has 
a  degree  egual  to  the  ditference  of  the  degrees  of  the  t*o 
relations,  Ihe  division  operation  is  aemonstrated  using 
relations  rell  and  rel2  and  dividing  rell  oy  rel2  v-here  the 
degrees  of  rell  and  rel2  are  rr  and  n  respectively  v-ith  m  >  = 
n,  Ihe  resultant  relation  consists  of  the  first  Cnn-n) 
attribute  values  for  each  tuple  in  the  dividend  ,  rell,  such 
that  every  tuple  in  the  divisor,  rel2#  exists  as  the  last  n 
attribute  values  of  the  uniguely  determined  partial  tuples 
[identical  first  (m-n)  attribute  values]  in  rell.  For 
exarrple  if  a  relation  X  has  tuples  aped,  abef,  bccd,  and 
abab,  and  relation  Y  has  tuples  cd  and  ef  then  X  divided  cy 
Y  *ould  be  the  relation  containing  the  tuple  ab.  The  tuple 
ab  *ouid  exist  in  the  resultant  relation  since  abed  and  abef 
are  in  X,  Ho*ever,  the  tuple  be  would  not  appear  since  beef 
is  not  in  X, 

RETRIEVE  (rell,attrl,  rell,attr2,  ..,  ,  rell  .attr (m-n) ) 
WHERE   COUNT  Crel2.attri)  a 

CCUNT  Crell,attri  by  rell,attrl, 

reii,attr2#  ,«•»  rell  ,attr Cm-n  ) 
WHERE    rell  ,attr  CfT-n  +  l)  =  rel2,attrl 
AND   rell.attr  Crn-n-f2)  =  rel2.attr2 
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AND 

AND    rell.attrm  =  rel2,attrn) 

5,  The  Union  Cperatlon 

Union  is  the  traditional  set-theoretic  definition  of 
union  with  the  additional  constraint  of  reouiring  the  t*o 
relations  to  be  union-ccrrpatible.  Union-corrpatibillty 
stipulates  that  the  two  relations  trust  be  of  the  saire  deqree 
and  the  correspondina  attribute  values  must  be  ta<en  from 
the  same  domain  (e.g.,  rell.attrlc  and  rel2,attr<  must  be 
defined  over  the  same  domain).  The  union  of  two  union- 
compatible  relations  is  the  set  of  all  tuples  belonging  to 
either  relation  or  both  relations.  Note  that  duplicates  are 
not  automatically  eliminated  cut  a  RETRIEVE  UMGUE 
(union.rel .ALL)  can  be  executed  after  the  following  example 
to  display  the  union, 

RETRIEVE  INTO  union. rel  (reil.ali) 
i«HERE  <qualif ication> 

APPEND  TO  union. rel  (attri  =  rei2.attrl, 
attr2  a  rel2.attr2,  ,..,  attrlast  =  rel2.attrlast ) 
WHERE  <quallf ication> 

6,  The  Intersection  Operation 

Intersection  is  only  defined  for  union-compatible 
relations.  The  resultant  relation  is  compriseo  of  tuples 
which  exist  identically  in  both  of  the  relations. 
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RETRIEVE  UNIQUE  (rell.allj 

WHERE  rell.attrl  =  rei2,attrl 

AND  reli,attr2  =  rei2,attr2 

AND  .  .  • 

AND  reil.attrlast  =  rel2,attrlast 

7,  The  Cartesian-Product  Cceratlon 

Given  two  relations, rell  and  rel2,  of  degree  in  and  n 
respectively,  the  Cartesian  product  is  the  set  of  all  tuples 
of  degree  (m  +  n)  fortted  by  taking  the  first  tuple  in  rell  and 
concatenating  to  it  all  tuples  Cone  at  a  time)  in  rel2.  This 
process  is  then  repeated  for  the  second  tuple  in  rell  until 
all  tuples  in  rell  have  been  concatenated  with  every  tuple 
in  rel2. 

RETRIEVE  UNIQUE  Crell.all,  rei2,all) 

8,  The  Difference  Operation 

The  difference  of  two  union-compatible  relations  is 
the  set  of  tuples  in  the  first  relation  but  not  in  the 
second. 

RETRIEVE  UNIQUE  (rell. ALL) 

WHERE  0  =  ANY  Crell.attrl  BY  rell.attrl 
WHERE   rell.attrl  =  rei2.attrl 
AND 
AND    reil.attrlast  =  rel2.attrlast ) 
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This  query  requires  each  tuple  In  rell  to  be 
compared  wltft  every  tuple  Ir  rel2t  In  the  above  example,  it 
is  assufred  that  rell.attrl  Is  the  key  for  the  relation.  In 
the  event  a  relation  has  a  coirposite  key,  the  rell.attrl 
following  the  BY  can  be  replaced  by  a  linear  list  of 
attributes  cotrprlsing  the  key. 
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IV,   THE  DATABASE  ACMIMSTPATOR 

The  role  of  DBA  is  to  establish  the  database  and  to 
ensure  that  the  database  systeir  is  responsive  to  the  user's 
perfortrance  requirements  and  information  needs.  Although 
the  discussion  of  DBA  will  use  RD't^  1100  as  the  target 
system,  the  facilities  described  and  DBA  support  required 
Should  be  applicable  to  any  relational  database  management 
system.  In  particular,  the  amount  of  DBA  support  required 
does  not  depend  on  a  particular  system.  If  tne  system  does 
not  provide  certain  facilities,  DBA  will  be  required  to 
reformat  and/or  extract  the  infcrnration  from  tne  database  to 
satisfy  the  users  information  needs.  Finally,  DBA  will  be 
referred  to  as  an  individual;  however*  the  functions  can  be 
the  responsibility  of  a  group  of  people. 

This  section  will  discuss  the  functions  and 
qualifications  of  DBA  in  the  areas  of  database  environment, 
database  design,  system  services,  user  services,  security, 
and  performance  enhancement.  For  each  area,  a  generalized 
statement  concerning  DBA  functions  and  qualifications  will 
be  provided;  then  a  specific  description  of  the  function  in 
the  RDM  1100  environment  will  follow,  RDM  IIOO  feature 
which  supports  it. 
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A.  THE  DATABASE  SYSTEM  ENVIRCN>'ENT 

A  software  database  managenrent  systerr  Is  designed  to 
support  a  single  database  en  a  general-purpose  coirputer. 
The  advantage  of  a  backend  relational  database  iracnine  Is 
tne  support  which  can  be  provlaed  to  multiple  nests  and 
ffultlpie  databases.  The  existence  of  rrultlple  databases  on 
a  single  irachine  creates  txo  levels  of  management.  Level 
one,  the  systerr.  DBA,  is  prirrarily  concernea  with  macnine- 
wlde  perforrrance  and  establishing  authorizations  for  the 
database  DBAs,  Level  two,  the  datacase  DfiAs,  is  concernea 
with  the  operational  data  in  the  individual  databases,  DBA 
and  system  DBA  should  be  knowledgeable  in  the  areas  outlined 
above  to  ensure  efficient  and  reliacle  database  performance. 

In  PDM  1100  the  systerr  DBA  has  control  of  a  datacase 
called  the  system  database.  Certain  commands  such  as 
creating  and  destroying  databases  can  be  issued  only  from 
the  system  database,  Knhen  a  new  database  is  created  the 
individual  issuing  the  CREATE  DATABASE  command  will  be  DBA 
for  that  database.  In  this  thesis  DBA  win  refer  to  the 
level-two  DBA  unless  otherwise  indicated. 

B,  THE  DATABASE  DESIGN  -  THE  PHYSICAL  AND  CCNCEPTUAL 
SCHEMAS 

As  alluded  to  above,  DBA  has  numerous  areas  of  concern. 
The  second  area  to  be  addressed  is  the  database  design. 
This  topic  describes  the  design  of  the  physical   schema   and 
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the  conceptual  scherra,  A  schefra  Is  slrrply  a  plan  for  a 
particular  level  of  the  database.  The  third  level,  external 
schema,  '*/ill  be  addressed  In  Section  iv  C, 

The  physical  schema,  also  called  the  internal  schema,  is 
a  plan  for  the  actual  storage  of  data  on  the  physical 
devices  available  to  the  database.  In  RCM  llOO  each  disk  is 
divided  into  zones  of  180  2K-byte  blocks.  The  first  block 
in  each  zone  is  reserved  for  a  directory  to  the  contents  ot 
that  block.  The  nurrber  of  blocks  reauired  for  a  relation  is 
dependent  on  the  nujrber  of  tuples  and  the  length  of  the 
tuples.  Since  the  physical  schema  is  a  function  of  the 
database  system,  the  major  issue  from  the  DBA  perspective  is 
whether  the  system  allows  the  location  of  data  and  indices 
to  be  explicitly  specified. 

The  conceptual  schema  is  the  logical  plan  normally 
associated  with  the  entire  'organizational  view'  ana 
instituted  by  DBA,  As  the  physical  schema  is  comprised  of 
the  actual  location  and  storage  structure  of  the  entire 
database,  the  conceptual  schema  includes  the  names  of  all 
relations,  indices,  and  data  dictionary  entries  in  the 
database. 

The  primary  guery  language  subset  used  to  define  the 
conceptual  and  physical  schemas  is  the  data  definition 
language.  The  mapping  between  the  physical  and  conceptual 
schema  is  performed  oy  the  database  system,  Tnis  mapping  is 
built  as  the  objects  are  mace  known  to  the  database  system. 
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In  RQL  the  CREATE  <object>  conrrrands  are  the  primary 
connfnands  employed  to  specify  the  conceptual  and  physical 
schemas.  The  database  systerr  \*111  construct  a  data 
dictionary  for  each  object.  This  includes  maKinq  the  object 
known  to  the  system,  reservlnc  appropriate  storage,  and 
describing  the  appearance  of  the  object  Ce.Q,,  nurrber,  size, 
and  type  of  attributes),  in  order  to  design  the  physical 
and  conceptual  scherras,  DBA  (rust  icnow  the  organizational 
structure  and  rrust  understand  database  noriralization ,  the 
database  systerr  architecture,  and  the  concents  of  data 
sharing  and  ownership, 

1  •   Organizational  Structure 

Since  CEA  is  responsible  for  ensuring  that  the 
database  reflects  the  'real  world'  of  the  organization  it 
supports,  there  is  ample  justification  for  a  good  working 
knowledge  of  the  organization.  The  objective  is  to  develop 
a  plan  which  will  accurately  reflect  the  organizational 
reguirements  without  a  need  to  continuously  redesign  the 
database.  Although  it  is  terrcting  to  limit  the  application 
to  one  functional  area  like  personnel,  DBA  must  be  aware  of 
the  relationships  between  the  personnel  and  other  entities 
in  the  organization,  without  a  total  oraanizational  picture 
DflA  will  ultimately  be  faced  with  redesign  to  meet  the 
organization's  needs. 
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2.  Norinalization 

In  order  to  enhance  database  reliability  and  reduce 
redundancYi  a  solid  foundation  in  relational  database  desian 
principles  is  required.  Cne  extremely  iir.portant  aspect  is 
the  DBA's  understanding  of  ncrrraiizatlon,  Cnce  a  specific 
norrral  forfr  is  established  for  a  database,  ueA  must  realize 
the  possible  implications  of  deviations  frotr,  a  this  noriral 
forir.  and  should  document  the  exceptions.  Normal  forms  are 
not  specifically  discussed  in  this  thesis  and  the  reader  is 
directed  to  tfief,  7]  for  more  information. 

The  RDM  1100  system,  like  most  existing  relational 
systems,  requires  only  that  all  relations  be  in  first  normal 
form.  This  normal  form  stipulates  that  each  attribute  value 
in  a  relation  must  be  atomic.  That  is,  tne  value  is  not 
decomposable.  Further,  there  is  only  a  single-value 
selected  from  the  specific  domain  for  an  attribute.  Higher 
normal  forms  must  ce  enforced  by  CBA, 

3,  Database  System  Architecture 

DBA  must  also  understand  the  architecture  of  the 
database  system  to  exploit  efficiencies  or  avoid 
deficiencies.  Since  database  users  do  not  have  static 
applications  and  the  data  stored  is  also  dynamic,  DBA  must 
icnow  how  to  monitor  and  enhance  performance.  If  possicle, 
when  user  requirements  can  no  longer  be  satisfied, 
requirements. 
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4.  Data  Sharing  and  CwrersMc 

One  of  the  primary  reasons  for  employing  a  database 
iranagennent  systeir  Is  to  snare  the  data  among  users.  This 
provides  a  reduction  In  the  storage  of  redundant  data  and 
alleviates  the  possibility  of  anomalies  associated  with 
redundancy.  The  concept  of  sharing  data  must  be  temperea 
with  the  regulrements  of  user  needs  and  information 
security.  Therefore,  a  mears  Tust  ce  available  to  provide 
control  over  the  data  and  to  permit  the  controlling 
authority  to  decide  who  will  have  access  to  the  data  he 
controls. 

In  RDM  1100  the  control  of  data  Is  a  function  of 
ownership  and  access  rights.  The  creator  of  an  object  Is  the 
owner  of  that  object.  Objects  wnlch  may  be  owned  are 
databases,  relations,  views  and  stored  commands.  The  owner 
of  the  object  must  explicitly  permit  other  users  (less  DBA) 
to  access  the  object  or  portions  of  an  object  (e,g,, 
specific  relation  attribute  values),  For  a  more  detailed 
discussion  of  ownership  and  access  rights,  see  Section  IV  C, 

5,  Recommendations 

In  database  design  the  first  step  Is  to  develop  a 
strategy  to  meet  the  organizational  information 
regulrements,  since  the  conceptual  schema  is  the 
comprehensive  data  description  of  the  organizational 
Information  structure,  the  second  step  would  entail  the 
designing  of  the  conceptual  schema.   By  using  this  approach, 


41 


data  Independence  can  be  nraintalned  which  will  prevent  the 
modification  of  applications  prograrns  due  to  changes  In  the 
physical  database.  Further,  the  dependencies  between  the 
conceptual  scherra  and  user  requlrerrents  can  oe  documented  to 
ensure  changes  at  the  conceptual  level  will  not  result  in 
changes  to  the  applications  programs. 

It  should  oe  noted  that  DBA  must  control  the 
creation  of  relations  and  Indices  in  such  a  manner  so  that  a 
specific  normal  form  can  be  maintained.  In  addition  to 
conforming  to  the  irrposed-normal  form  constraints,  each  user 
creating  relations  to  satisfy  his  own  needs  must  not  violate 
the  relations  of  the  database  supporting  other  users.  Such 
violation  will  certainly  contain  excessive  and  redundant 
information,  and  undermine  the  initial  database  design. 
Additionally,  if  individuals  sharing  a  database  are 
permitted  to  create  objects  at  will,  the  sharing  of  aata  oy 
all  users  may  be  subverted  and  the  database  could  rapidly 
deteriorate  to  a  user-determined  tiling  system, 

C,   THE  DATABASE  CE5IGN  -  THE  EXTERNAL  SCHEMA 

As  important  as  the  physical  and  conceptual  schemas  are 
to  the  implementation  of  a  single  database,  the 
establishment  of  the  external  schema  is  critical  to  the 
users.  In  considering  divergent  user  application 
reguirements ,  the  external  schema  provides  the  means  to 
define   precisely   what   will  satisfy  each  users  information 
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needs.  The  external  scherra  cf  the  database  Is  different  for 
each  user  or  group  of  users.  These  scneiras  are  corrpcsed  of 
subsets  of  the  conceptual  schetra.  The  definition  of  the 
contents  of  a  particular  external  schema  Is  norrrally 
accotrpllshed  through  access  control  of  objects  existing  at 
the  conceptual  level,  ay  restricting  the  relations, 
attributes,  stored  corrmands,  and/or  views  available  to  a 
user,  a  subset  of  the  entire  datacase  is  aeflned, 

A  user's  access  to  the  database  is  deterrrined  by  the 
user's  access  rights.  The  access  rights  of  a  user  are 
authorized  by  DBA  and  consequently  DEA  controls  user  access 
to  the  database.  In  addition  to  the  verification  and 
matching  of  host  ID  and  hcst-user  ID  to  the  database 
system-user  ID,  these  access  rights  are  the  only  means  for 
access  control  in  the  majority  cf  aatabase  systems.  In  RQL 
the  PERNiIT  and  DENY  commands  on  physical  objects,  virtual 
objects,  and  stored  commands  car  be  used  to  establish  the 
various  external  scnemas  of  the  database. 

1 .   Permit/Denv  Access 

There  are  two  access  rights  which  must  be  available 
in  a  database  system  to  provide  a  user  *ith  the  appropriate 
level  of  information.  These  access  rights  are  read  and 
write.  Execute  privileges  can  be  considered  a  special  case 
cf  indirect  read/v^rite  just  as  create  can  be  a  special  case 
of  write. 
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The  two  corrrrands  In  RQL  wMch  assign  the  access 
rights  are  FEPyil  and  DENY,  Ihe  PERMIT  command  grants  a 
user  a  specified  access  right  over  an  object  or  comftand  and 
the  DEN^  corrirand  revokes  or  removes  such  access  rights, 
DENY  is  primarily  employed  to  revoke  a  previously  granted 
PERMIT, 

The  access  rights  available  in  RGL  are  READ,  write, 
EXECUTE,  and  CREATE.  PERMIT  READ  provides  access  to  the 
specified  objects  (relation,  view  or  named  attributes  of  a 
relation  or  view).  To  modify  or  add  data  to  existing 
relations  in  the  database  a  PERMIT  «RITE  for  the  user  or 
group  of  users  on  the  objects  or  portions  of  objects  must  be 
explicitly  authorized.  The  keyword  ALL  can  be  used  to  grant 
read,  write,  and  execute  privileges  to  a  user  or  group  of 
users.  Only  the  owner  of  the  object  is  authorized  to  DENY 
access  to  the  object. 

There  are  two  cases  of  implicit  access  in  RDM  1100, 
DBA  is  authorized  access  to  all  objects  In  the  database  to 
which  he  has  not  been  explicitly  denied  access  oy  the  owner. 
Even  if  access  is  denied  to  DBA  by  the  owner,  DBA  may  still 
destroy  the  object  by  deleting  all  references  to  it  in  the 
database  relations  (non-user).  Additionally,  the  owner  of 
any  object  is  permitted  access  to  that  opject.  All  other 
accesses  must  be  authorized  by  the  o*ner  of  the  object. 
This  is  the  essence  of  the  access  control  system. 
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2.   Create  Physical  Objects 

The  database  iTanagerrent  system  must  provide 
facilities  to  create  physical  objects  in  tne  database. 
Initially,  the  database  trust  be  created  with  an  assigned 
DBA,  Following  this,  the  physical  objects  in  tne  database 
must  be  created.  Although  an  index  is  not  a  physical  object 
which  (nay  be  manipulated  by  the  user,  it  is  discussed  in 
this  topic. 

In  RQL  the  right  to  execute  the  CREATE  DATA6ASE 
command  must  be  explicitly  granted  by  the  system  DBA,  Once 
a  user  has  authorization  to  create  a  database,  the  execution 
of  the  CREATE  DATABASE  command  maxes  him  DBA  of  the  named 
database.  To  add  new  users  to  the  database,  C3A  employs  the 
database  administrator  utilities  ccbau)  program.  The  DEAU 
NEW. USERS  command  assigns  the  host-user  ID  and  host  ID  and 
places  them  in  the  HCST.USERS  relation.  The  DESTROY 
DATABASE  command  can  only  be  executed  by  DBA,  ci.e,,  the 
owner  of  the  database), 

CREATE  <objects>  is  alsc  controlled  throuqn  the 
PERMIT  and  DENY  commands.  The  permission  is  similar  to 
CREATE  DATABASE  in  that  only  DBA  for  a  particular  database 
may  authorize  the  creation  of  objects.  Relations  and 
indices  are  the  physical  objects  which  a  user  may  be 
authorized  to  create.  Only  the  owner  of  a  relation  is 
allowed  to  create  an  index  on  the  relation  using  the  CREATE 
INDEX   command.    However,   the  DBA  must  authorize  the  owner 
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use  of  the  CREATE  INDEX  ccrrrrand.  Each  of  the  above 
discussed  cotrtrands  has  a  counterpart  for  revocation.  Only 
the  owner  or  C8A  rray  destroy  relations  and  Indices, 

3,  Create  Virtual  Objects 

Once  the  physical  objects  are  created,  it  is 
necessary  to  create  the  virtual  objects  in  the  conceptual 
schema  which  will  define  the  external  schema  for  each  user. 
Views  are  the  virtual  objects  *Mch  a  user  rray  ce  authorized 
to  create, 

CREATE  VIEW  requires  the  user  to  nave  access  to  the 
relations  over  which  the  view  is  defined.  Only  the  owner  of 
the  view  iray  destroy  the  view  with  the  DESTROY  <ot3ject> 
coinfr.and, 

4,  Access  Via  Stored  Comrards 

Finally,  an  indirect  read/write  (execute)  access  is 
necessary  to  allow  users  to  extract  inforination  froir  the 
database  through  the  use  of  stored  commands.  Stored  command 
is  an  RQL  term  for  a  user  defined  function  or  procedure. 
Although  this  feature  may  not  be  available  in  every  database 
system,  it  Is  very  useful  and  powerful  when  provided.  In 
addition  to  the  efficiency  issue  of  stored  commands 
discussed  previously,  it  is  mucn  easier  for  the  user  to 
execute  stored  commands  than  to  input  long  queries.  In  RQL 
PERMIT  EXECUTE  allows  a  specified  user  or  group  of  users  to 
execute  stored  commands. 
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5,   RecofTfrendatlors 

There  are  three  rrethods  fcr  providing  an  external 
schema  to  a  user  or  group  of  users.  The  first  rriethod  is 
through  restriction  of  access  or  the  physical  objects  in  the 
database.  The  second  method  Is  to  define  virtual  relations 
which  consist  only  of  the  necessary  subset  of  data  the  user 
is  required  to  access.  Finally,  the  third  metnod  entails 
the  extraction  of  information  from  the  database  through  the 
exclusive  use  of  stored  commands. 

In  RQL  the  major  problems  with  the  first  two  miethods 
are  the  addition  and  deletion  of  data  and  imolementat ion  ot 
ALL.  As  mentioned  in  Section  III  there  are  too  many 
restrictions  on  the  use  of  views  for  updating  database. 
Additional  problems  can  arise  using  the  first  method  as  a 
result  of  the  system  assigning  default  values  to  attributes 
wnlch  are  not  explicitly  listed  in  an  APPtND  command.  For 
example,  an  insertion  of  a  tuple  with  a  blank  Key  field 
(employee  number)  for  a  new  employee's  salary  and  name  would 
result  in  a  tuple  containing  the  employee's  name  and  salary 
with  a  blank  key  field,  A  separate  insertion  containing  the 
employee  number  and  name  would  result  in  two  tuples  in  the 
same  relation  for  a  single  employee. 

The  stored  command  can  be  executed  without  granting 
the  user  access  rights  to  the  relationCs)  which  are  accessed 
by  the  commana.  However,  exclusive  use  of  stored  commands 
for   information   retrieval    is   not   reasonable   since 


47 


anticipation  of  every  query  which  a  user  could  possibly 
require  is  not  possible. 

There  is  a  trade-off  between  access  control, 
performance,  and  relational  perspective.  Each  of  these 
issues  requires  the  sacrifice  of  one  of  the  trade-off 
features.  In  order  to  resolve  this  protleir,  a  combination 
of  the  prescribed  irethods  is  required.  The  use  of  stored 
corrrrands  to  input  and  delete  data  in  a  well  structured 
database  removes  the  restrictions  on  tne  use  of  views. 
Further,  stored  commands  car  force  the  entry  of  all 
mandatory  attribute  values  for  a  tuple  through  parameter- 
argument  matching  which  eliminates  the  duplicate  tuple 
problem  described  above.  Combining  stored  commands  for 
updating  with  the  use  of  views  to  oefine  tne  external 
schemas  would  provide  the  most  logical  approach,  in  order 
to  employ  this  strategy  a  major  system  change  is  reouired  in 
the  implementation  of  ALL, 

First,  it  should  be  obvious  that  the  most  logical 
mechanism  for  producing  an  external  schema  is  the  view. 
However,  the  major  problem  is  the  necessity  to  provide 
access  to  the  ATTRIBUTE  relation  to  permit  the  use  of  ALL 
with  the  view  name.  Therefore,  ALL  should  be  implemented 
such  that  only  the  attributes  or  relations  the  users  are 
authorized  to  access  are  returned.  Tnis  should  not  carry  an 
implicit  access  to  the  ATTRIEUTE  relation.  Access  to  the 
ATTRIBUTE  relation  can  be   restricted   by   implicit   use   ot 
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user-Id  predicates  on  all  queries  on  data  dictionary 
relations.  The  performance  issue  results  from  the 
Irtipierrentation  of  ALL  in  tne  host  and  the  resultant 
ccrrmunicatlons  between  the  host  and  tne  bacicend  to  process  a 
query  containing  ALL.  This  performance  degradation  can  be 
rectified  by  irrpleirenting  ALL  in  the  bacKend  relational 
database  machine, 

D,   SYSTEM  SERVICES 

The  third  area  is  the  services  provided  to  DBA  by  the 
system,  DBA  will  use  these  services  to  facilitate  system 
backup,  crash  recovery  and  provide  information  about  the 
database.  The  system  services  establish  a  nucleus  ot 
information  and  facilities  which  ceA  may  be  required  to 
augment  for  his  own  personal  preferences  and  needs, 

1  •   System  BacKup 

Two  areas  of  system  backup  must  be  provided  to  DBA 
to  ensure  proper  system  functicning.  The  first  area  is  the 
necessity  of  providing  a  means  to  record  the  contents  of  the 
database  when  it  is  in  a  consistent  state.  This  is  employed 
most  frequently  by  the  system  CEA  and  is  addressed  further 
in  the  next  topic  on  crash  recovery. 

The  second  area  is  the  neeo  to  return  the  database 
to  a  previous  consistent  state  as  a  result  of  aborting  a 
transaction,  A  transaction  is  a  single  command  or  a  series 
of   commands   which  must  be  left  uncommitted  until  the  final 
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coiT.rrand  has  finished.  This  situation  can  result  froir  a  user 
decision  to  abort  his  transactlcn  prior  to  completion  or  the 
necessity  of  rolling  a  transaction  cack  as  a  result  of 
deadloclc.  Deadlock  occurs  in  a  truitiple  user  system  when 
one  user  holds  a  resource  (e.g.,  relations)  another  user 
requires  and  the  second  user  holds  a  resource  tne  first 
requires.  In  this  situation,  the  system  is  said  to  be 
deadlocked  since  neither  user  can  complete  his  transaction. 
To  resolve  deadlock  only  one  of  the  transactions  must  be 
rolled  back.  The  solution  to  user  aborts  is  to  restore  the 
database  to  the  state  it  *as  in  prior  to  the  abort. 

In  RDM  1100  the  function  of  backina  up  transactions 
is  invisible  to  DBA.  The  TRANSACT  relation  (to  be  discussed 
later)  is  used  to  maintain  the  before  and  after  attribute 
values  affected  by  the  transaction  for  relations  created 
with  the  logging  option.  The  aATCH  relation  is  used  for  the 
other  relations,  A  transaction  is  by  default  a  single 
command  unless  the  explicit  ccirtrands  BEGIN  cefore  and  END 
TRANSACTICN  after  a  group  of  ccnrmands  is  specified,  ABCRT 
TRANSACTION  can  then  be  issued  after  BEGIN  and  before  END  to 
cause  rollback,  RDM  llOO  employs  an  optimistic  concurrency 
control  algorithm  *hich  does  not  prevent  deadlock  from 
occurring.  The  resolution  of  deaalock  is  completely 
invisible  to  the  user  and  DEA, 
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2.   Crash  Reccvery 

Anotner  facility  which  frust  te  provided  to  cba  is 
the  ability  to  recover  frcir  a  system  malfunction.  This  is 
particularly  irrportant  when  the  data  on  the  disK  has  teen 
lost  or  contairinated.  To  avoid  excessive  tin^e  delays, 
periodic  copies  of  the  entire  database  must  oe  rraoe  to 
reduce  the  amount  of  updating.  The  frequency  of  copying  the 
database  is  dictated  by  the  nunrber  of  cnanges  in  a  period  of 
time  and  the  tiffe  demands  of  the  applications  programs.  The 
normal  method  of  recovery  requires  the  most  recent  copy  of 
the  database  and  the  transactions  vxhicn  have  occurred  since 
the  copy  v-as  Ka6e,  Once  the  copy  of  the  oatabase  is  loaded, 
the  transactions  are  rerun  to  bring  the  dataoase  up  to  date. 
Since  the  chronological  list  of  transactions  is  the  key  to 
recovery,  it  must  be  copied  from  the  database  on  a  freouent 
basis  even  though  the  copying  of  the  entire  database  may  be 
less  freauent  due  to  the  time  required.  Of  course,  some 
transaction  *hich  were  in  progress  or  not  in  a  transaction 
list  must  be  reinitiated  by  the  user, 

RDM  UOO  provides  DUMP  DATABASE  and  LCAD  DATABASE 
commands  in  the  DBAU  facility.  Adaiticnally,  DUMP 
TRANSACTION  is  provided  to  make  copies  of  the  transaction 
log.  The  command  which  allows  rerunning  transactions  after 
a  LOAD  DATABASE  command  has  beer  executed  is  fiOLLFDP-*APD, 
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3,   Svsterr  Information 

The  database  system  etrployed  must  provide  a  data 
dictionary  and  statistical  irfcrmatlon  on  the  database 
conf iQuratlon  and  performance,  A  data  dictionary  contains 
descriptive  Information  about  the  database.  It  must  include 
all  the  various  schemas  (physical,  conceptual,  external)  and 
should  include  cross-ref erepce  information  such  as  which 
programs  use  what  data  and  syrcnyrrs. 

In  RDW  1100  there  are  13  system-supplied  database 
relations  which  contain  descriptive  information  about  the 
associated  database.  In  addition,  there  are  seven  system 
relations  which  provide  a  global  description  of  the  database 
machine. 

The  system  relations  provide  a  catalog  of  the 
databases  in  PCM  llOO,  a  list  cf  diSKS  known  to  the  system, 
status  and  types  of  locks  in  the  system  (used  for  concurrent 
processing),  and  the  configuration  of  the  communlcaticns 
interface  to  the  attached  hcstCs),  Another  system  relation 
provides  information  concerning  tne  activity  currently 
taking  place  in  the  database.  T*c  additional  relations  are 
used  to  provide  performance  data. 

Perhaps  more  important  for  CBa  are  the  13  relations 
associated  *ith  each  database,  Each  relation  is  listed 
below  and  a  brief  description  of  the  type  of  information 
contained  is  provided.   The  first  11  are  used  to  supply  data 
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dictionary  Inforiration  and  the  last  two  provide   Information 
related  to  transaction  rranagenrent . 


RELATION  NAME 


RELATION 


CESCRIFTICN 

A  Single  tuple  is  provided  for  each 
object  in  the  database.   This  tuple 
Includes,  as  appropriate,  the  naire  of 
the  Object,  cv^ner,  relation  identi- 
fication nurrber,  size,  location, 
number  of  tuples  and  their  length, 
type  of  object  (user,  system,  trans- 
action log,  file,  view  or  stored 
co(rrpand),  and  the  number  of 
attributes. 


ATTRIBUTE 


A  tuple  Is  entered  for  every  attribute 
In  the  database.   This  tuple  includes 
the  attribute  identification  nurrber, 
data  type,  (raxirr.utn  length,  assoclateo 
relation  ID,  and  attribute  name. 


INDICES 


Each  index  has  a  tuple  in  the  rela- 
tion.  The  attributes  Include  the 
index  identification  nun-cer,  relation 
ID,  nurrber  of  attributes  in  the  index, 
location,  and  attrioute  ID(s), 
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PROTECT 


Contains  Irfcrrratlon  associated  iivith 

the  explicit  access  authorized  on  ocjects 

for  users  In  tne  database. 


QUERY 


CRQSSREF 


USERS 


HOST. USERS 


BLCCKALLCC 


DISK. USAGE 
DESCRIPTIONS 


Contains  the  stored  comir'ands  and 
views . 

Describes  the  dependencies  arrong 
relaticns,  indices  and  stored 
cornirands  in  the  datacase.   The  deoend- 
encies  are  system  defined  and  not  user 
specified. 

Describes  the  (nappings  between  user 
identification  numbers^  names,  and 
user  groups. 

Defines  the  irapping  cetween  the  nost 
ID,  host-user  ID,  and  RDM  IIOO  user  ID, 

Catalogs  the  sector  assignment  within 
a  zone.   Each  tuple  represents  a  sector 
and  the  assigned  ocject. 

Describes  database  disk  allocation. 

Contains  user-specified,  textual 
descriptions  of  objects  and  attributes 
in  the  database. 
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BATCH 


Contains  terrporary  loqqing  Inforn^atlcn 
used  by  the  system  for  transaction 
iranagerrent .   This  relation  orovldes 
information  on  transactions  against 
logged  and  non-logged  relations  so 
they  can  be  canceled  if  required. 
The  transaction  information  is  held 
until  the  transaction  is  committed. 


TRANSACT 


Permanent  logging  information  used 
for  crash  recovery. 


All  cf  the  above  relations  provide  the  comprenensive 
picture  of  the  database.  Although  the  information  is  in  the 
relations,  much  of  it  is  rot  in  a  usable  format.  For 
example,  only  the  RELATICN  relation  contains  the  textual 
name  of  a  relation.  Other  relations  use  the  internally 
assigned  relation  ID,  Further,  some  of  the  Information  is 
encoded.  In  order  to  translate  this  information  into  an 
understandable  format  DBA  must  develop  stored  commands 
(preferable  to  ad  hoc  queries).  The  number  of  stored 
commands  will  be  dependent  on  the  desires  of  DBA,  However, 
a  minimum  subset  should  include  commands  to  list  the 
relations,  attributes,  indices,  attributes  in  an  index, 
access  list  associated  v»ith  an  object,  description  of  an 
object,  and  dependencies. 
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The  following  stored  ccftrrands  are  used  to  yield  the 
mlnlmutr  subset,  TABLES  Is  used  tc  provide  a  list  of  objects 
by  type  (CBA-suFPlied  paraireter  tc  TABLES),  For  relations, 
relation  name,  type,  and  the  nuirber  of  attributes  and  tuples 
in  the  relation  are  provided.  FIELDS  provides  the  relation 
name  (paranneter  specified  by  DBA  to  FIELDS),  attribute  narre, 
data  type  of  the  attribute  (bin,  char,  int,  etc),  and  the 
length  of  the  attribute  for  every  attribute  in  the  relation, 
ALL.INDICES  provides  a  list  of  all  indices  on  user  relations 
in  the  database.  The  infcrrration  provided  includes  the 
relation  name,  index  identification  number,  number  of 
attributes  in  the  index,  and  a  narrative  description  of  the 
type  of  index.  An  additional  command,  INDEX.LIST,  is  used 
to  provide  the  same  infcrmaticn  as  ALL.INDICES  except  a 
relation/view  name  is  passed  as  a  parameter  and  only  the 
indices  on  that  relation/view  are  returned,  att.in.incxi 
and  ATT-IN.INDX2  are  used  to  list  the  attributes  in  an  index 
by  name.  These  commands  require  two  parameters;  the  index 
ID  and  the  relation  name.  The  reason  for  the  development  of 
two  separate  commands  is  the  readaoility  of  the  output, 
PRCTECTION  provides  the  object  name,  user  name,  and  type  of 
access  authorized  for  an  object  which  is  passea  as  a 
parameter.  Another  command,  ACCESS«LIST,  is  provided  to 
describe  an  object  and  the  associated  access  list  for  a 
particular  object,  whatis  provides  a  narrative  explanation 
of   its  parameter  from  the  CESCRIFTICN  relation,   DEPENDS  is 
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used  to  provide  a  list  of  the  dependencies  on  an  object. 
Finally,  another  useful  corrirand  is  aHQCREATES  which  crevices 
a  list  of  users  who  t^ave  ceen  granted  create  perirission  in 
the  database,  RQL  constructs  for  the  stored  comrrands 
described  above  are  provided  in  Appendix  A, 
4.   Iranslator 

Upon  inrpleirentation  of  a  relational  database,  it 
will  be  necessary  to  load  the  data  into  the  systerr.  Since 
the  data  exists  on  soire  storage  device  CdisK,  tace,  etc,), 
there  should  be  a  inechanisiT  for  presenting  the  data  to  the 
system  for  Irr.rrediate  loading  In  a  relational  forrrat. 

In  PC^  1100,  assuming  the  data  can  be  collated  as  a 
sequence  of  records  on  a  disk  cr  tape,  tne  'translator'  can 
then  be  used  to  load  the  database  on  a  reiation-by-relation 
basis.  The  'translator'  will  ask  a  series  of  Questions  to 
ascertain  the  incoming  data  format  and  establish  the 
relation  scnema.  The  following  questions  must  be  answereo 
for  a  relation.   The  answers  are  parenthesized, 

1.  Output  directly  to  the  PCM?   Cy/n) 

2.  Input  file   (name) 

3.  Database   (name) 

4.  Name  of  table   (relation  name)         * 

5.  Name  of  1st  field   (name  of  first  attribute) 

6.  Enter  input  type  and  length   Cinput  file  format) 

7.  Enter  output  type  and  length   Ccl2>  11,  etc,) 
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8,  Starting  position   (input  file) 
(Questions   5   through   8   are   repeated 
attribute.) 

9,  Record  length  (input  file) 


for    each 


E.   USER  SERVICES 

The  fourth  area  is  DBA  support  provided  to  the  users  of 
the  relation  database  systefr,  DBA  should  provide 
services/facilities  to  the  users  of  the  database  depending 
on  their  applications  and  experience  level,  a  discussion  of 
user  services  in  t*o  general  areas  *lll  be  addressed.  These 
areas  are  providing  a  help  facility  and  providing  stored 
cornirands, 

1,   Help  Facility 

As  with  any  Interactive  systerr»  a  help  facility  is 
required  to  preclude  tifre-ccnsuiring,  trial-and-errcr 
corrective  procedures.  For  a  relational  database  systerri  the 
help  facility  should  include,  at  a  minirr.utr,  the  syntax  and 
explanation  of  every  language  ccrrirand  and  an  explanation  of 
the  stored  comtands,  relations,  and  vie*s. 

In  RGL  this  can  be  accoirplished  by  creating  a  help 
relation  with  three  attributes  (object,  line  nurrber,  and 
text)  and  defining  a  stored  corrrrand  *nich  given  an  ooject  as 
a  parameter  will  explain  its  purpose  or  use.  The  stored 
coirnrand  (pust  contain  appropriate  prealcates  in  tne  wHfcRE 
clause  to  ensure  the  user  can  only  retrieve  Inforrration  from 
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the  help  relation  about  objects  which  he  is  authorized 
access.  An  exairple  of  the  help  relation  and  stored  corrrrano 
is  provided  in  Appendix  A, 

2,   Stored  Coffirapds  Provided  by  DBA 

DBA  iTust  have  an  ir-depth  knowiedqe  ot  the  query 
language.  It  is  not  reasonable  to  assume  that  the  average 
user  will  becotre  proficient  in  tne  use  of  the  query 
language.  Both  query  language  complexity  and  perf orirance 
issues  must  be  considered.  The  examples  in  Sections  111  and 
V  demonstrate  some  of  the  complexities  in  RCL,  LEA  will  ce 
required  to  assist  the  user  in  the  proper  for^iulation  of 
some  queries.  In  addition,  the  users  will  loox  for 
assistance  when  confronted  with  any  perceived  problem  in  the 
database.  Since  DBA  is  a  database  expert,  the  user  will 
naturally  request  his  assistance. 

In  addition  to  applications  oriented  RQL  stored 
commands,  which  are  not  discussed,  DEA  should  provide 
commands  similar  to  those  described  earlier  in  this  section 
for  the  user.  Specifically,  DEFENDS,  nHATIS,  FRCT£C1ICN, 
ATT.IN.INDXl,  ATT-IN.INDX2,  INDEX. LIST,  FIELDS,  TABLES,  and 
HELP  should  be  provided.  The  only  difference  between  the 
DBA  commands  and  the  user's  stored  commands  is  the  inclusion 
of  the  necessary  predicates  in  the  where  clause  to  limit  the 
response  to  data  which  the  user  has  been  granted  access. 
Other  minor  modifications  may  also  be  desired.  For  example, 
TABLES  could  be   parameter  less   and   return   all   relations, 
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views,  and  stored  coirtrands  to  which  the  user  has  access. 
PROTECTION  could  be  rrodified  to  return  only  the  accesses  en 
objects  the  user  owns, 

F.   SECURITY 

The  fifth  area  for  DBA  concern  Is  the  security  of  the 
database.  The  security  of  a  database  system  Is  plagued  with 
the  same  problems  associated  with  corrputer  security  in 
general.  The  norrral  iTiechanlsm  for  security  Is  access 
control.  Since  a  database  system  is  attached  (backend)  to  a 
host,  the  security  measures  provided  by  the  host  are  the 
first  level  of  security  afforded  the  datacase  system.  The 
user  ID-password  logon  procedure  employed  by  generai-purocse 
computers  can  be  used  for  database  systems  to  provide  the 
same  security  checks,  Addlticnaliy ,  a  host  ID  check  in 
conjunction  with  the  previously  mentioned  validation  can  be 
performed  when  a  backend  system  is  used.  Security  is  also 
afforded  by  the  backend  machine  configuration  since  the 
database  machine  is  separate  from  the  host  and  uses  its  own 
disks  for  data  storage. 

The  first  security  check  performed  oy  RDM  iioo  is  the 
verification  of  the  host  and  host-user  ID.  These  IDs  are 
verified  each  time  a  request  is  made  from  tne  host  to  the 
backend  machine.  Since  the  security  of  the  database  is 
closely  associated  with  the  security  of  the  host,  the  use  of 
passwords  on  the  host  for  identification  and  verification  is 
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essential.  The  user  ID-passwcrd  logon  procedure  is  not 
employed  In  FDM  1100  but  Is  taken  froir^  the  nost  which  means 
there  is  not  an  additional  IC-password  required  for  the 
backend  frachine.  In  addition  to  the  verification  and 
watching  of  host  ID  and  host-user  ID  to  the  database 
systerr-user  ID,  the  access  control  riqhts  are  the  only 
security  fnechanisrrs  availaole  in  hDM  ilOO, 

There  are  two  implicit  access  rights  in  RDM  HOC.  The 
owner  (creator)  of  any  object  and  DBA  are  permitted  access 
to  that  object  unless  explicitly  denied  by  tne  owner.  All 
other  accesses  must  be  authorized  py  the  owner  of  the 
object,  Thisis  the  essence  of  the  security  system.  The 
remainder  of  this  topic  will  discuss  specific  security 
weaknesses  in  the  PCM  liOO, 

1 ,   Security  Aspects  cf  *ALL* 

A  crucial  aspect  for  security  is  the  implementation 
of  ALL,  ALL  is  used  in  a  query  as  a  synonym  for  every 
attribute  of  the  relation  in  the  target  list.  As  previously 
discussed,  there  is  not  a  user  ID  qualltlcaticn  associated 
with  ALL,  Therefore,  the  translation  of  ALL  to  its 
attribute  equivalents  is  based  on  cne  object  (relation  or 
view),  ALL  does  not  work  with  a  view  or  a  relation  unless 
the  user  has  BEAD  access  en  the  ATTRIBUTE  relation. 
However,  once  this  access  is  authorized,  the  user  can 
examine  the  entire  conceptual  schema  which  is  certainly  a 
violation  of  security. 
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2,  SysteiT    Messages 

The  use  of  relation. attrlbuteCs )  or 
vlew.attrlbute(s)  in  the  target  list  returns  f^o  seoarate 
error  messages  if  read  access  to  the  object  is  rot 
permitted.  One  error  message  (permission  denied  on  ,,,) 
indicates  the  attribute  name  is  valid  but  access  is  not 
authorized.  The  other  error  message  (,.,  not  found)  can  be 
interpreted  as  the  attribute  name  is  non-existent.  Although 
extremely  tedious,  the  error  messages  can  be  used  in  a 
trail-and-error  method  to  obtain  the  conceptual  schema. 

3,  User  Identification  Numbers 

Another  serious  weakness  in  the  security  of  ROL  is 
the  deletion  of  a  user  from  a  database.  The  easiest  method 
is  to  delete  the  user  from  the  HCST.USEHS  relation  which 
will  prohibit  him  from  opening  the  database.  However,  if  a 
new  user  is  added  to  the  database  from  DBAU  and  the  system 
assigns  him  the  UID  which  was  previously  assigned  to  a 
deleted  user,  the  new  user  will  inherit  all  the  accesses 
which  were  established  by  DBA  and  owners  for  that  UID,  This 
is  not  acceptable  since  there  should  not  be  any  implicit 
authorizations  for  a  new  user, 

4,  Recommendations 

The  recommendations  for  correcting  the 
implementation  of  ALL  are  discussed  in  Section  IV  C5  above. 
Although  not  as  informative,  the  return  of  a  single  error 
message   for   both   access  denied  and  relation, attribute  not 
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found  would  provide  less  Inforrration  about  the  conceptual 
schema  of  the  database.  Frcir  a  user's  perspective  it  does 
not  appear  to  be  significant  whether  access  Is  denied  or  the 
object  is  not  in  the  database.  The  critical  issue  is  to 
avoid  divulgence  of  the  conceptual  schema  to  a  user  not 
authorized  this  inforrration. 

The  tvko  methods  for  correcting  the  user  ID  problem 
are  the  explicit  deletion  of  all  access  rights  in  the 
database  (PROTECT,  USERS,  HCST.USERS)  for  the  old  user  by 
DBA,  or  providing  a  corrrrand  in  the  DBAU  to  delete  a  user 
from  a  specified  database  which  will  explicitly  remove  all 
the  accesses  the  u-ser  has  been  granted.  The  second  metnod  is 
preferable  to  the  first  since  the  system  should  provide  this 
service  to  DBA, 

G,   FINE-TUNING  PERFORMANCE 

The  last  area  of  concern  for  DBA  is  the  performance 
enhancement  of  an  existing  database.  Given  that  a 
relational  database  system  has  already  been  selected  and  the 
overall  performance  factors  have  been  established,  DBA 
nevertheless  does  have  a  few  tools  at  his  disposal  which  can 
enhance  performance.  There  are  features  in  the  auery 
language  implementation  which  are  more  efficient  than 
others.  For  example,  a  join  can  run  faster  depending  on 
which  relation  is  held  in  cache,  Cne  language  uses  the  last 
relation   listed   in   the   query  if  other  factors  are  equal. 
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Thus,  the  order  of  the  relations  could  be  Irrcortant, 
Another  example  is  the  use  of  parenthesis  to  resolve 
aiTbiguity  in  a  list  of  logical  predicates.  These  features 
are  highly  iirpleinentaticn-dependent  and  '*ill  not  be 
addressed  further.  The  other  three  features  are  data 
reorganization,  indices,  and  data  placeirent. 

In  RQL  DBA  \(»1H  be  reouired  to  develop  a  performance 
ironitoring  strategy  which  (ray  include  the  periodic  execution 
of  stored  coirrrands  specifically  designed  to  collect 
perf ornrance  data, 

1  •   Data  Reorganization 

As  data  is  added  to  and  deleted  from  the  database, 
there  is  an  associated  fragmentation  of  relations  in 
physical  storage.  Even  though  many  database  systems  provide 
the  capability  to  reserve  extra  space  tor  relations,  this 
will  result  only  in  a  delay  of  fragmentation.  The  extent  of 
fragmentation  must  be  monitored  and  fragmentation  eiiminatea 
when  necessary, 

DBA  may  specify  the  number  of  blocks  for  a  database 
and  for  a  relation  in  RQL,  Additionally,  FILLFACTORs  can  be 
specified  for  clustered  indices  on  relations.  This 
FILLFACTOR  determines  the  percentage  of  each  disk  blocx 
which  will  be  used  for  the  data  in  the  relation  when  a 
clustered  index  is  created,  when  the  fragmentation  becomes 
excessive,  the  clustered  index  can  be  destroyed,  recreated, 
and   a   new  FILLFACTOR  assigned.   This  procedure  will  resort 
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the  data  in  the  blocks  available  for  the  relation.  A 
relation  will  be  allowed  to  orow  until  It  uses  all  the 
blocks  It  Is  authorized  or  all  blocks  In  the  database  are 
full.  Since  blocks  are  not  re-used  when  data  is  oeleted 
froir  a  relation,  this  will  result  in  reaching  rraximum  block 
capacity  and  f ragfrentation.  DBA  can  ftionltcr  this  activity 
by  writing  a  stored  corrrrand  or  the  BLGCj^S  relation.  The 
ability  to  eiirrlnate  f  ragrrentation  tor  a  non-indexea 
relation  win  depend  on  the  nurrcer  of  free  consecutive 
blocks  available  in  the  database.  If  enough  blocks  are 
available,  the  data  can  be  retrieved  into  a  teirporary 
relation  defined  over  the  eirpty  blocks,  the  original 
relation  destroyed,  and  the  terrporary  relation  renamed. 
This  strategy  can  also  be  enrplcyed  when  reclustering  does 
not  offer  a  satisfactory  solution  to  f ragirentation, 
2.   Indices 

Indices  can  enhance  the  perforinance  of  a  database 
for  data  retrieval,  CRef.  2]  and  [Ref.  33  have  documented 
the  actual  enhancetrent  in  PCM  1100,  Since  indices  are 
application-oriented,  they  are  highly  desiraole  for 
databases  where  the  majority  of  operations  are  retrieval  of 
data  over  large  relations  or  relations  which  are  fairly 
static  can  be  identified.  If  numerous  uodate  and  apoend 
transactions  are  envisioned,  then  a  degradation  in 
performance  could  result  due  to  the  constant  updating  of  the 
indices.   Therefore,   DBA  should  be  aware  of  the  size  of  the 
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relations   and   types   of   operations    performed    on    the 
relations.    For   example.   If   insertion   is  prevalent  then 
avoidance  of  Indices  en  the  relations  wnich  require  numerous 
APPENDS,  if  possible,  may  reduce  degradation, 
3,   Data  Placement 

Hypotnetically ,  the  placement  of  data  on  disxs  can 
enhance  performance.  For  example,  if  a  join  between  t*o 
relations  is  performed  frequently,  then  placing  the 
relations  on  separate  disks  will  reduce  disk  head  movement 
as  data  is  moved  into  cache,  Althouqn  this  hypothesis  has 
not  been  verified  due  to  the  lacX  of  facilities  for  placing 
data  in  RQL,  the  data  placement  strategy  should  ce 
considered  when  exoiicit  assignment  of  physical  storage  is 
available.  This  could  be  even  more  significant  when 
processing  data  on-the-fly  is  reaiizea,  considering  the 
speed  discrepancy  between  reading  data  and  moving  dis< 
heads. 


66 


V,   EVALUATION  OF  ThE  RELATIONAL  SYSTEM 

A,   THE  FULLY  RELATIONAL  SYSTEM 

1 ,   The  Fully  Relational  Characteristics 

The  definition  of  a  "fully  relational"  database 
rranagerrent  systerr  is  given  ty  Chris  Date  [Ref,  7],  Date 
suggests  that  (rest  existing  systeTis  are  not  fully 
relational.  The  prirrary  benefit  of  considering  fully 
relational  as  a  standard  and  goal  for  irrrlementaticn  is  in 
the  algebraic  pc'*er  of  the  language  and  tne  consistency  of 
systetr  supplied  functions.  If  the  syster  is  deficient  in 
any  characteristics  which  Date  describes,  appropriate  action 
tray  be  taken  to  provide  a  seirblance  of  a  fully  relational 
systeir.  First,  the  concept  of  fully  relational  is  defined; 
then  a  comparison  of  HDf^  1100  and  RtiL  to  the  definition  is 
addressed. 

In  order  for  a  database  to  pe  characterized  as  fully 
relational  it  rrust  support  tne  following: 

a.  "relational  databases  (includina  the  concepts  of 
domain  and  Key  and  the  tvko  integrity  rules);" 

b,  "a  language  that  is  as  powerful  as  the  relational 
algebra  (and  that  *culd  remain  so  even  if  all 
facilities  for  loops  and  recursion  were  to  be 
deleted)."  [Ref,  7] 


67 


A  relational  database  exhibits  the  following 
properties: 

a.  Relations  are  in  first  ncrrrai  forni. 

b.  Associations   tetimeen   relations   are    explicitly 
connected  through  corrrrcn  attributes. 

c.  Every  value  appearing  in  a  given  attribute  is  taken 
from  the  doniain  for  that  attribute, 

d.  Every  relation   has   a   unique   primary   key   which 
distinguishes  Cidentifies)  individual  tuples. 

In  addition  to  the  above  properties,  two  integrity 
rules  are  required.  First,  a  null  value  is  not  permissible 
as  an  attribute  value  of  a  prirrary  key.  Second,  if  a 
relation  A  has  an  attribute  value  whicn  is  also  the  primary 
key  of  another  relation  B,  tnen  at  all  tirres  the  attribute 
values  in  relation  A  must  exist  in  b.  This  rule  prevents  the 
missing  linkages  among  relations  vvhen  attribute  values  are 
added  to  relation  A  or  removed  from  relation  B, 
2 t   Four  Areas  of  Deficiency 

There  are  four  areas  in  which  RDM  llOO  does  not  meet 
the  requirements  for  a  fully  relational  system.  First, 
although  specification  of  the  schema  includes  data  types  for 
each  attribute,  no  notion  of  an  underlying  domain  is 
incorporated.  Since  attributes  are  defined  cy  general 
length  and  type  comparisons  of  attributes  are  limited  only 
to   similar   types    (e,g,,    character    with    character), 
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nfieanlngless  co»rparlsons  are  allcwed,  without  the  concepts  of 
sets,  enumerated  tyces,  and  ranges  avallaoie  In  hiqher  order 
languages  such  as  PASCAL  or  ACA,  the  support  of  doir.ains  will 
always  oe  questionable. 

second,  the  requireirent  for  a  unique  primary  <ey  is 
not  enforced.  The  uniqueness  of  an  attribute  value  can  be 
enforced  by  declaring  a  unique  index  on  one  of  the  candidate 
Keys,  However,  this  associates  an  access  path  with  the 
concept  of  a  icey.  These  are  two  logically  separate  issues 
and  as  such  should  be  dealt  witn  separately,  since  the 
e.xistence  of  a  candidate  key  does  not  irnply  the  need  for  an 
access  path  on  that  attribute. 

Third,  nulls  are  net  implemented  in  RDM  llOO, 
However,  the  default  values  for  integers  (zero)  and 
characters  Cblanxs)  are  provided  for  unspecified  attribute 
values,  TupleCsD  may  be  entered  into  a  relation  without 
values  for  the  key  fields.  Even  if  unique  attribute  values 
are  enforced  through  index  specification,  at  least  one  tuple 
with  the  default  value  in  the  key  attribute  will  be 
accepted. 

Finally,  relations  are  ncrmaily  connected  through 
the  repetition  of  some  (or  aiiD  of  the  key  attribute  values 
in  one  relation  A  and  in  another  relation  B,  However,  there 
is  no  mechanism  to  ensure  relation  E  does  not  contain  a 
value  in  the  connecting  attribute  *hich  does  not  exist  in 
relation  A, 
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3.   The  Relational  Corrpleteness 

RDM  1100  perforins  all  the  relational  algetra 
operations  defined  in  Section  III  *ith  one  exception.  This 
exception  deals  with  the  eliirination  of  duplicate  tuples  in 
the  results  after  applying  certain  operators  (projection, 
division,  natural  join,  etc),  Fcr  example,  althougn  the 
result  relation  rray  appear  to  satisfy  a  natural  join,  it  is 
obvious  that  duplicates  are  net  a  priori  eliminated,  since 
the  elimination  is  a  function  cf  the  associated  projection. 
Additionally,  a  projection  cf  ar  attribute  in  a  relation 
with  duplicate  entries  will  return  all  the  values  in  the 
attribute  without  regard  to  duplicates,  A  join  could  be 
simulated  by  forming  a  Cartesian  product  of  the  two 
relations,  applying  the  predicates  to  the  product, 
extracting  the  concatenated  tuples  which  satisfy  the 
predicates,  and  projecting  the  attributes  from  the  target 
list. 

B.   COMPARISON  CF  TWO  QUERY  LANGUAGES 

This  topic  provides  a  ccmparison  of  RGL  and  SGL,  The 
selection  of  SQL  as  the  comparative  language  is  based  on  the 
relative  familiarity  of  a  large  numper  of  people  with  the 
language  and  its  widespread  use, 

1  •   i:guai  Power 

The  power  of  the  two  guery  languages  is  practically 
identical.    Both   languages  are  relationaily  complete  which 
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implies: 

a.  Any  relation  derivable  from  the  database  relations 
using  an  expression  in  the  relational  aloebra  can  ce 
retrieved  using  the  language,  and 

b.  Any  derivable  relation  can  oe  retrieved  using  a 
single  staterrent  in  the  language, 

2t   Differences  in  the  Syntax  Structure 

The  rr,ajor  difference  between  SQL  and  RQL  is  the 
syntactic  structure.  Using  the  database  in  Figure  1  from 
Date,  an  example  of  the  two  guery  languages  will  be  given. 

This  example  is  a  guery  to  list  the  names  of  all 
suppliers  who  do  not  provide  part  "P2".  As  can  seen  from 
inspection  of  Figure  1  the  answer  would  be  one  supplier, 
ADA/^S. 

SQL:  SELECT  SNAME 

FRCM  S 
WHERE  'P2'    !=  ALL 

(SELECT  P_NR 
FRCM  SP 

The  guery  as  stated  in  RQL  is: 

RQL:     RETRIEVE  (S,SNA^*E)  WHERE  C  s  ANY  (SP.P-NR  BY 

S. SNAME 
WHERE   SP.P.NP  =  "P2'' 

AND   S.S, NR  3  SP.S.NR)  GO 


71 


S.NR 

SNAf^E 

STATUS 

CITY 

SI 

SMITH 

20 

LONDON 

S2 

JCNES 

10 

FAHIS 

S3 

BLAKE 

30 

f  ARI5 

54 

CLARK 

20 

LO.NDCN 

S5 

ADAMS 

30 

AlnE.NS 

P,NR 


PNAME 


CCLCR 


ili^IGHl 


CITY 


PI 

NUT 

RED 

12 

LONDCN 

P2 

6CLT 

GREEN 

17 

PARIS 

P3 

SCPEW 

BLUE 

17 

ROME 

P4 

SCRE* 

RED 

14 

LCNCCN 

P5 

CAM 

BLUE 

12 

PARIS 

P6 

CCG 

RED 

19 

LO\DCN 

SP 


S.NR 


P.NR 


OTY 


SI 

PI 

300 

51 

P2 

200 

51 

P3 

400 

SI 

P4 

200 

SI 

P5 

100 

SI 

P6 

100 

52 

PI 

3CC 

52 

P2 

40C 

S3 

P2 

200 

54 

P2 

200 

54 

P4 

300 

54 

P5 

400 

Figure  1,   The  Supplier-Parts  Database 
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Without  regard  to  iirclerrertdtlon  the  above  queries 
are  resolved  as  follows: 

a.  In  the  SQL  exarrple  the  sets  of  suppliers  and  the 
parts  they  supply  is  fcrrred  by  the  nested  select.  Then 
the  outer  select  win  return  a  supplier's  narre,  if  ana 
only  if  the  set  of  parts  supplied  oy  tnat  supplier  dees 
not  contain  ''F2". 

fc.  In  the  PGL  exarrple  the  "fcy"  clause  establishes  the 
same  set  as  the  inner  select  of  the  SQL  query.  Then  the 
two  boolean  expressions  are  evaluated  with  the  "and" 
conjunction.  If  no  tuples  satisfy  tne  conaitions  for  a 
given  supplier,  then  the  value  of  ANi  (tuple)  is  0,  If 
ANY  is  0,  the  qualification  evaluates  to  true,  and  the 
suppliers  naire  is  returned.  s.S^nr  =  SP.S.NR  Insures 
that  suppliers  in  the  S  relation  but  not  in  tne  SP 
relation  are  not  ignored  (i.e.,  that  a  supplier  vnho 
supplies  no  parts  v^ill  be  included  as  a  tuple  in  the 
answer  to  the  query). 

The  syntactic  structure  of  the  exairple  derronstrates 
the  major  differences  in  the  t*c  languages.  SQL  is  highly 
structured,  *ith  nested  selects.  On  tne  other  hand,  SOL 
does  not  permit  nesting  of  retrieves  cut  ailovi>s  nesting  of 
aggregate  functions  to  perform  the  same  operations. 
Although  it  would  be  purely  subjective  to  favor  one  method 
over  the  other,  it  appears  that  the  structured  approach  of 
SQL   may   be   easier   to  learr  initially.   However,  once  the 
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aggregate   functions   of   RGL   are   irastered,   the   lacK   ct 
redundancy  rnay  be  irore  attractive, 
3.   Other  Differences 

RDM  1100  dees  not  irrpleirert  nulls,  but  does  sunply 
default  values  (zeros  for  ruireric  fields,  blanks  tor 
character  fields).  Therefore,  tne  results  of  the  scalar 
aggregates  and  aggregate  functions  (AVG,  wiN,  MAX,  and  6U^^ 
are  not  always  predictable.  This  Itrpiies  the  user  must  be 
extreirely  knowledgeable  about  the  database  and  use  the 
aggregates  with  caution  Ce,g,,  explicitly  exclude  zero 
values  from  aggregation).  In  SQL  queries  can  be  constructed 
with  "no  null"  as  a  qualifier  and  the  tuples  with  null 
values  in  the  attribute  being  aggregated  will  not  be 
included  in  the  returned  value, 

SOL  uses  'ALL',  'HAVING',  'IN',  and  others  to 
provide  a  rrore  set-theoretic  description  of  database 
rnanlpulation,  ROL  provides  the  same  capability  in  the 
aggregate  functions  but  the  concept  of  set  rranipulation  is 
not  explicit,  ROL  provides  a  'fcC  function  and  sonne  string 
iranipulation  functions  which  are  also  available  in  SQL,  The 
string  manipulation  functions  extend  the  power  of  KGL 
particularly  when  working  with  database  relations  Cl,e,, 
non-user  defined  relations)  which  have  attributes  encoded  as 
binary  values. 

The  'MCC  function  is  not  correctly  impienrented  for 
negative  numbers  in  ROL  or  SQL,   It  returns  the  modulo  class 
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of  the  argurrent  as  If  the  argunrent  *ere  a  positive  Integer 
and  'attaches'  the  original  sign.  For  exairple,  -1  mod  8  = 
-CI  mod  8)  =  -1,  To  avoid  this  inconsistency  and  to 
correctly  iirplerrent  the  rratherratical  definition,  the 
following  nested  application  of  irod  is  required  for  modulo 
8: 

trod  (mod  CARG,  6)  +  8,  8), 
The  actual  function  Irrplerrented  appears  to   be   a   remainder 
function    which    would   be   consistent   since   both   guery 
languages  are  implemented  in  the  programming  language  C.    C 
has  a  remainder  function  but  not  a  mod  function. 
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VI,   CONCLUSIONS 

There  are  three  major  areas  In  which  DBA  must  be 
Jcnowledgeable  In  order  to  ensure  the  successful  manaqement 
of  a  database  systein.  These  areas  are  tne  user  services, 
pert  orinance  enhancements,  and  security  factors.  The 
specific  relational  database  iraragerrent  system  or  fcacXena 
machine  employed  will  dictate  tne  amount  of  DBA  support 
required  in  each  area. 

The  user  services  include  the  stored  commands  providea 
by  DBA,  the  loading  of  data  into  the  system,  the  recovery  of 
the  database  as  a  result  of  system  malfunction,  and  a  help 
facility.  Although  these  are  not  comprehensive  and  the 
exact  amount  of  supp.ort  will  be  discretionary  on  the  part  of 
DBA,  they  do  form  the  nucleus  for  DBA's  planning  of  user 
support.  This  support  is  critical  to  the  acceptance  and  use 
of  the  relational  database  system  by  the  user  community. 

The  basic  tools  DBA  can  use  to  ennance  performance  are 
the  implementation  of  the  language  features,  indices,  ana 
data  placement.  The  performance  ennancement  which  can  be 
gained  from  the  query  language  is  only  achievable  if  DBA  has 
a  solid  understanding  of  the  language  and  how  it  is 
implemented.  Certain  features  of  the  language  will  be 
executed  faster  than  others  and  since  there  are  numerous 
ways   to  form  a  query  to  obtain   the  same  information, 
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knowledge  about  these  characteristics  can  achieve  mere  rapid 
responses  frotr  the  database.  Therefore,  DBA  should  review 
user  commands  in  applications  programs  and  provide  guidance 
to  users  for  the  purpose  of  exploiting  the  more  rapia 
features,  Gf  course,  the  specific  features  will  vary 
between  languages. 

Indices  provide  another  performance  tool  in  databases 
where  retrieval  and  joins  are  the  primary  operations.  Even 
if  these  operations  are  not  the  most  prevalent,  indices  may 
still  De  employed  to  enhance  performance.  If  tne  database 
has  a  large  number  of  insertion  operations,  then  avoiding 
the  placement  of  indices  on  the  relations  which  are  changing 
freguently  will  not  result  in  serious  degradation 
attributable  to  the  index  updating.  Additionally,  if 
relations  in  this  type  of  database  Ahich  are  not  sucject  to 
frequent  insertions  but  are  used  in  numerous  retrieves  and 
joins  can  be  identified;  then  placement  of  indices  on  these 
relations  over  the  appropriate  attributes  "*ill  enhance  tne 
overall  performance  of  the  database  system. 

The  ability  to  explicitly  place  aata  in  the  database 
should  provide  a  more  responsive  system.  In  order  to  take 
advantage  of  data  placement  DSA  must  know  what  relations 
exist  in  the  system  and  which  ores  are  joined  on  a  recurring 
basis. 

The  security  aspects  on  a  relational  database  system 
should  be  a  critical  issue  for  CBA.   since  a  single  database 


77 


will  be  used  by  various  users  In  the  organization,  there 
will  be  data  which  certain  groups  of  users  do  not  reaulre  to 
perforin  their  functions  and  ttcre  Irrportantly,  they  shoula 
not  be  allowed  to  access.  Although  there  is  more  to 
security  than  access  control,  this  appears  to  be  the  only 
rnechanlsm  available  to  DBA  to  lirplenrent  a  security  system  in 
the  database.  Consequently,  access  control  should  be 
employed  to  restrict  the  data  available  to  the  users  and 
simultaneously,  provide  a  relational  database  perspective  to 
each  user. 

In  RDM  1100  there  Is  a  trade-off  between  security, 
performance,  and  relational  perspective.  There  were  three 
methods  discussed  to  provide  a  single  external  view  of  the 
database  to  a  user  or  group  cf  user.  Each  of  these  methods 
required  the  sacrifice  of  one  of  the  traae-off  features  ana 
In  order  to  resolve  this  problem,  a  change  in  the 
Implementation  of  ALL  is  necessary. 

The  features  and  Issues  discussed  in  this  thesis  should 
provide  DBA  with  some  guidelines  and  topics  to  investigate 
which  will  make  his  database  system  acceptable  and 
responsive  to  the  users.  Although  the  success  or  failure  of 
any  system  cannot  be  realistically  placed  on  a  single 
individual,  it  appears  DBA  will  be  more  responsiole  than  any 
other  person  connected  with  the  system  if  it  does  not  meet 
the  users  perceived  needs. 
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APPENDIX  A 
EXAMPLES  OF  STORED  COMMANDS 

ACCESS-LIST 

DESTROY  ACCESS. LIST  GO 

DEFINE  ACCESS. LIST 

RETRIEVE  (RELATION. NAME,  RELATION  .TliPE  , 

FIELDS  s  RELATION, ATTCNT,  RECORDS  s  RELATION , TUPS  , 
USER  s  USERS, NAME) 
WHERE  RELATION, NAME  =  SO 

AND  PROTECT. RELID  =  RELATION . PELID 
AND  PROTECT, USER  =  USERS, ID 

AND  MOD  CINTl  (SUBSTRING  (1,  1,  PROTECT .  ATTMAP ) D ,  4)  =  1 
END  DEFINE  GO 

ASSOCIATE  ACCESS. LIST  wITH  "RETURNS  ACCESS  LIST  FOR  AN 

OBJECT"  GO 

ALL-INDICES 

DESTROY  ISTATUS  GO 

CREATE  ISTATUS  (STATUS  =  II,  DESC  a  030)  GO 

APPEND  TO  ISTATUS  (STATUS  =  0, 

DESC  =  "NONUNIQ-NONCLUS-NO  DEL  SILENT") 
APPEND  TO  ISTATUS  (STATUS  =  1, 
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DESC  =  "UNIG-NCNCLUS-NQ  DEL  SILENT") 
APPEND  TO  ISTATUS  (STATUS  =  2, 

DESC  =  "NCNUNIG-CLUS-NO  DEL  SILENT") 
APPEND  TO  ISTATUS  (STATUS  =  3, 

DESC  =  "UNIQ-CLUS-NO  DEL  SILENT") 
APPEND  TO  ISTATUS  (STATUS  =  4, 

DESC  =  "NCNUMG-NCNCLUS-DEL  SILEiJT") 
APPEND  TO  ISTATUS  (STATUS  =  5, 

DESC  3  "UNIG-NCNCLUS-DEL  SILENT") 
APPEND  TO  ISTATUS  (STATUS  =  6, 

DESC  =  "NONUNIQ-CLUS-DEL  SILENT") 
APPEND  TO  ISTATUS  (STATUS  =  1, 

DESC  =  "UMG-CLUS-DEL  SILENT") 
PERMIT  READ  OF  ISTATUS  TO  ALL 
DENY  WRITE  OF  ISTATUS  TO  ALL  GO 
DESTROY  ALL. INDICES  GO 
DEFINE  ALL. INDICES 

RETRIEVE  (REL  =  REL.NAME  ( INDICES . RELID ) ,  INDICES , INDID , 

INDICES, ATTCNT,  ISTATUS . DESC ) 
ORDER  BY  REL. NAME  ( INDICES , REL ID ) 

WHERE  ISTATUS, STATUS  =  MCD  (f*CD  ( INDICES  .STAT ,  8)  +  8,  8) 
AND  RELATION. RELID  =  INDICES , RELID 
AND  RELATION. TYPE  =  "U" 
END  DEFINE  GO 
ASSOCIATE  ALL. INDICES  WITH  "LIST  ALL  INDICES  ON  USER 

RELATIONS"  GO 
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ATT.IN.INCXl 


DESTROY  ATT-IN.INCXl  GO 
DEFINE  AIT.IN.INDXl 
RETRIEVE  (INDICES, INDID, 

ATTl  5  FIELD. NAME  ( IND ICES  ,  RELID 

C4,  1 
ATT2  s  FIELD. NAME  ( IND ICES . RELID 

(14,  1 
ATT3  =  FIELD-NAME  ( IND ICES  ,  RELID 

(24,  1 
ATT4  s  FIELD. NAME  ( INDICES , RELID 

(34,  1 
ATT5  =  FIELD. NAME  ( INDICES  .  kElIL 

(44,  1 
ATT6  s  FIELD. NAME  CIND  ICES , hELiD 

(54,  1 
ATT7  =  FIELD. NAME  ( IND ICES , RELID 

(64,  1 
ATT8  s  FIELD-NAME  ( I NDICES . RELID 

(74,  1 
WHERE  INDICES, INDID  =  SO 

AND  INDICES, RELID  s  REL.ID  (51) 
END  DEFINE  GO 
ASSOCIATE  ATT-IN.INDXl  WITH  "LISTS  NAMES 


INTl  (SUBSTRING 
INDICES, KEYS))), 
INTl  (SUBSTRING 
INDICES, KEYS) ))  , 
INTl  (SUBSTRING 
INDICES, KEYS) )) , 
INII  (SUBSTRING 
INDICES. KEYS)))  , 
INTl  (SUBSTRING 
INDICES. KEYS)))  , 
INTl  (SUBSTRING 
INDICES, KEYS)  ))  , 
INTl  (SUBSTRING 
INDICES, KEYS)  )  )  , 
INTl  (SUBSTRING 
INDICES. KEYS)))) 


CF  ATTRIBUTES  IN 
INDEX"  GC 
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ATT-IN-INCX2 


DESTROY  ATT-IN.INDX2  GO 
DEFINE  ATT.IN.INDX2 
RETRIEVE  (INDICES.INDID, 

AITS  =  FIELD. NAME  ( INDICES  ,  RELID ,  INTl  (SUBSTRING 

(84,  1,  INDICES. KEYS))  )  , 
ATTIO  =  FIELD.NAME  (INDICES , RELID ,  INTl  (SUBSTRING 

(94,  1 
ATTll  =  FIELD. NAME  ( INDICES , RELID 

(104,  1 
ATT12  =  FIELD. NAME  ( INDICES . RELID 

(114,  1 
ATT13  =  FIELD. NAME  ( IND ICES , RtLID 

(124,  1 
ATT14  s  FIELD. NAME  ( IND ICES .RELID 

(134,  1 
ATT15  3  FIELD. NAME  ( INDICES  .  RELID 

(144,  1 
ATT16  3  FIELD.NAME  ( INDICES  .  RELID 

(154,  1 
WHERE  INDICES, INDID  =  SO 

AND  INDICES. RELID  '    PEL-ID  (Si) 
END  DEFINE  GO 
ASSOCIATE  ATI.IN.INDX2  v^ITH  "LISTS  NAMES  CF  ATTRIBUTES  IN 

INDEX"  GO 


INDICES. KEYS))) , 

INTl  (SUBSTRING 
INDICES. KEYS) )) , 
INTl  (SUBSTRING 
INDICES. KEYS))), 
INTl  (SUBSTRING 
INDICES. KEYS))) , 
INTl  (SUBSTRING 
INDICES. KEYS) )), 
INTl  (SUBSTRING 
INDICES. KEYS))), 
INTl  (SUBSTRING 
INDICES, KEYS)))) 
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DEPENCS 

DESTROY  DEPENDS  GC 

DESTROY  OTYPE  GC 

CREATE  ClYPE  (TYPE  =  UCl,  DESC  =  UC15)  GC 

APPEND  TO  OTYPE  (TYPE  =  "U",  DESC  =  "UScR  TABLE      ")  GO 

APPEND  TO  OTYPE  (TYPE  =  "S",  DESC  =  "SYSTEM  TABLE    " )  GC 

APPEND  TO  OTYPE  (TYPE  =  "T",  DESC  =  "TRANSACTION  LOG")  GO 

APPEND  TO  OTYPE  (TYPE  a  "F",  DESC  =  "FILE  ")  GO 

APPEND  TO  OTYPE  (TYPE  s  "V",  DESC  =  "UShiR  VIEW       " )  GO 

APPEND  TO  OTYPE  (TYPE  =  "C",  DESC  =  "STORED  CC^^MAnD  ")  GO 

DENY  WRITE  OF  OTYPE  GC 

DENY  READ  OF  OTYPE  GO 

DEFINE  DEPENDS 

RETRIEVE  (OBJECT  =  RELATION . NA^E ,  WHICH. IS.A  = 

STRING  (15,  CTYFE.DESC),  DEPENDS. ON  =  SI) 
WHERE  CRCSSREF.RELID  =  REL«ID  (SI) 

AND  CRCSSREF.DRELID  =  REL AT lUN  ,  RELID 
AND  CIYPE.TYFE  =  RELATION . TYPE 
END  DEFINE  GO 
ASSOCIATE  DEPENDS  WITH  "LISTS  DEPENDENCIES  OF  THE  NAMED 

OBJECT"  GO 

FIELDS 


DESTROY  FIELDS  GO 
DESTROY  FIELD. EGUIV  GC 
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CREATE  FIELD. EQUIV  (NAME  s  UC4,  NUM  =  II)  GO 
APPEND  TC  FIELD-EGUIV  (NAME  =  "FLT  " ,  NUM  s  35)  GC 
APPEND  TO  FIELD. EGUIV  (NAME  =  "BIN  %  NUM  =  45)  GC 
APPEND  TO  FIELD-EGLIV  (NAWE  s  "CHAR",  NbM  s  47)  GC 
APPEND  TO  FIELD-EQUIV  (NAME  =  "InT  ",  NuM  =  48)  GC 
APPEND  TO  FIELD. EQUIV  (NAME  -  "INT  ",  NUM  s  52)  GO 
APPEND  TO  FIELD-EQUIV  (NAME  =  "INT  ",  NUV  s  56)  GC 
DEFINE  FIELDS 
RETRIEVE  (TA8LE  =  RELATION . NAME ,  FIELD  =  ATTP IBUTE . NAME , 

TYPE  =  FIELD. EGUIV, NAME,  LLN  =  ATTRIBUTE . LEN ) 
INHERE  ATTRIBUTE, RELID  =  REL  ATICN  ,  RhLlD 

AND  RELATION, NAME  =  STABLE. NAME 

AND  FIELD. EGUIV. NUM  =  ATTRIBUTE . TYPE 
END  DEFINE  GO 
ASSOCIATE  FIELDS  WITH  "RETURNS  ALL  FIELDS  IN  THE  NAMED 

RELATION"  GC 


HELP 


HELP. PEL 


OBJECT 


LINE-NC    DESCRIPTION 


ATT.lN.INDXl 


THIS  IS  A  STORED  COMMAND  WHICH  HAS 
TWO  PARAMETERS,   THE  FIRST  PARA- 
METER IS  THE  INDEX  ID  NO,  AND  THE 
SECOND  IS  THE  RELATION  NAME, 
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5 

6 

7 

8 

9 

10 

11 

12 


THESE  PARAMETERS  MUST  BE  SEPAR- 
ATED BY  CCMMAS.   THIS  COMMAND 
PRCVICES  TrtE  ATTRIBUTE  NAMES  OF 
EACH  ATTRIBUTE  IN  THE  INDEX  FOR 
THE  GIVEN  RELATICN  CR  VIEW,   TO 
EXECUTE  THIS  CQM^^AND  JUST  TYPE 
IN  "HELP"  FCLLOWED  BY  THE  OBJECT 
NAME  AND  "GO", 


DESTROY  HELP  GO 

DEFINE  HELP 

RETRIEVE  (HELP. PEL, DESCRIPTION) 

ORDER  BY  HELP. REL, LINE. NO  !  A 

WHERE  HELP. REL, OBJECT  =  SCEJECTNAME 

AND  PROTECT. RELID  =  PEL. ID  ( HELP-PEL .OBJECT ) 
AND  PROTECT, USER  =  USEPID  () 

AND  (MCD  CINIl  (SUBSTRING  Cl,  1,  PROTECT .  ATTMAP )) , 

4)  =  1) 
END  DEFINE  GO 

PERMIT  EXECUTE  OF  HELP  TO  ALL 

ASSOCIATE  HELP  VrlTH  "PROVIDES  INFORMATION  ABOUT  THE  OBJECT 

PASSED  AS  A  PARAMETER"  GO 

INDEX. LIST 

DESTROY  INDEX. LIST  GO 
DEFINE  INDEX. LIST 
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RETRIEVE  (RELATION. NAME,  INDICES  .  INDID  ,  INDICES , ATTCNT , 

.  ISTATUS.DESC) 
ORDER  BY  INDICES. INDIC 
V»HERE  INDICES. RELID  =  RELATION  .RELID 
AND  RELATION, NAME  =  $0 

AND  ISTATUS, STATUS  =  MOD  (MOD  ( INDICES .STAT ,  8) 

+  8,  8) 
END  DEFINE  GO 
ASSOCIATE  INDEX. LIST  WITH  "LIST  INDICES  ON  NAMED 

RELATION/VIEW"  GO 

PRCTECTICN 


") 
") 

") 


DESTROY  PTYPE  GO 

DESTROY  ATYPE  GO 

CREATE  PTYPE  (ACCESS  =  II,  DESC  =  UC15)  GC 

APPEND  TO  PTYPE  (ACCESS  =  1,  DESC  =  "HEAD 

APPEND  TO  PTYPE  (ACCESS  =  2,  DESC  =  "aHITE 

APPEND  TO  PTYPE  (ACCESS  =  3,  DESC  =  "ALL 

APPEND  TO  PTYPE  (ACCESS  =  -32,  DESC  =  "EXECUTE         ") 

APPEND  XO  PTYPE  (ACCESS  =  -53,  DESC  =  "CREATE  DATABASE") 

APPEND  TO  PTYPE  (ACCESS  =  -56,  DESC  =  "CREATE  " ) 

APPEND  TO  PTYPE  (ACCESS  =  -58,  DESC  =  "CREATE  INDEX    ")  GO 

PERMIT  READ  OF  PTYPE  GO 

DENY  >»RITE  OF  PTYPE  GO 

CREATE  ATYPE  (ACCESS  =  II,  DESC  =  UC8)  GO 

APPEND  TO  ATYPE  (ACCESS  =  1,  DESC  =  "PERMIT   ") 
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APPEND  TO  ATYFE  (ACCESS  s  2,  DESC  =  "DENY     ") 

APPEND  TO  ATYFE  (ACCESS  =  3,  CESC  =  "BOTH     " )  GC 

PtRMIT  HEAD  CF  ATYFE  GC 

DENY  WRITE  OF  ATYFE  GC 

DESTROY  PFQTtCTICN  GO 

DEFINE  PRCTECTICN 

RETRIEVE  (ACCESS  =  CONCAT  (ATYPE.CESC,  PTYPE.DESC), 

OBJECT  =  RELATION. NAME,  USER  =  USERS, ^A^'E) 
WHERE  ATYFE. ACCESS  s  mcD  (IMl  (SUBSTRING  (1,  1, 

PROTECT. ATTMAF) )  ,  4) 
AND  PTYPE, ACCESS  =  PROTECT . ACCESS 
AND  RELATION, RELID  s  PROTECT  ,  RELID 
AND  RELATION, NAME  =  SO 
AND  PROTECT, USER  =  USERS, ID 
END  DEFINE  GO 

ASSOCIATE  PROTECTION  wITH  "DISPLAY  PROTECTION  DATA  ABOUT 

THE  NAMED  RELATION"  GO 

TABLES 

DESTROY  TABLES  GO 

DEFINE  TABLES  GC 

RETRIEVE  (RELATION, NAME,  RELATION , TYPE  ,  FIELDS  = 

RELATION, ATTCNT,  RECORDS  =  RELATION , TUPS ) 

ORDER  BY  RELATION, NAME  :  A 

*HERE  RELATION, TYPE  =  SO 
END  DEFINE  GO 
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ASSOCIATE  TABLES  WITH  "RETURNS  LIST  CF  RELATIONS,  VIEWS  OR 

STCREC  CCMWANDo"  GC 

WHATIS 


DESTROY  WHATIS  GO 

DEFINE  WHATIS 

RETRIEVE  (RELATION  =  REL.NAME  (DESCRIPTIONS , RELID  )  , 

EXPLANATION  s  DESCRIPTIONS , TEXT ) 
WHERE  DESCRIPTIONS, RELID  =  PELOID  ($0) 
END  DEFINE  GO 
ASSOCIATE  WHATIS  WITH  "EXPLAINS  WHAl  A  STORED 

COMMAND/RELATION  DOES/IS"  GO 

WHCCP£AT£S 

DESTROY  WHOCREATES  GO 

DEFINE  WHCCREATES 

RETRIEVE  (USERS. NAME,  PTYPE.DESC) 

WHERE  PROTECT. USER  =  USERS. ID 

AND  (PROTECT. ACCESS  s  -53  OR  PROTECT . ACCESS  =  -56  OR 

PROTECT, ACCESS  =  -58) 
AND  PROTECT. ACCESS  =  PTYPE. ACCESS 

AND  MOD  (INTl  (SUBSTRING  (1,  1,  PROTECT , ATTMAP ))  , 

4)  =  i 
END  DEFINE  GO 
ASSOCIATE  WHCCREATES  WITH  "LIST  USERS  WHO  HAVE  CREATE 

PERMISSION"  GO 
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